%EB%8A%94%20SSD%EC%97%90%20%EC%93%B0%EA%B8%B0%20%EC%9E%91%EC%97%85%EC%9D%B4%20%EB%A7%A4%EC%9A%B0%20%EB%A7%8E%EC%95%84%20%EC%9D%BD%EA%B8%B0%20%EC%A0%84%EC%9A%A9%EC%9C%BC%EB%A1%9C%20%EB%8B%A4%EC%8B%9C%20%EC%84%A4%EC%B9%98%ED%95%A9%EB%8B%88%EB%8B%A4..png)
저는 Ubuntu 20.04(이전 19.04)를 실행하는 소규모 홈 서버를 운영하고 있습니다. 이 서버는 docker만 실행하고 일반적으로 내가 설치한 ZFS 풀에 데이터를 씁니다(이 이야기와는 관련이 없으며 단지 맥락상 관련이 없음).
부팅 디스크로는 EXT4 파일 시스템이 있는 Kingston A2000 512GB NVME 드라이브를 사용합니다. 오늘 오후와 이번 주에도 몇 차례 서버가 응답하지 않아 원격으로 로그인할 수 없었습니다. 화면에 연결한 후 오류로 인해 SSD가 읽기 전용으로 마운트된 것을 발견했습니다. 무슨 오류인지 알 수 없었습니다. 재부팅 후 SSD에 불량 섹터나 기타 문제가 있는지 확인하기로 결정했지만 아무것도 찾지 못했습니다. 하지만 SSD(반년)는 56TB를 썼지만 6TB를 읽었다는 점이 눈에 띄었습니다.
너무 많아서 정말 귀찮습니다. noatime 속성을 설정하고 정리를 실행 중입니다.
SSD에 저장되는 유일한 항목은 다음과 같습니다: +/- 30개의 Docker 컨테이너, Ubuntu 20.04 및 두 컨테이너의 일부 데이터(Plex 메타데이터, Minecraft 서버에 대한 일일 백업/파일을 실행하지 않는 비디오/Duplicati 데이터베이스, Docker에 포함된 내용) 자주 사용하지 않는 사용자 5명).
높은 쓰기의 밑바닥을 파악하려고 노력 중이지만 이를 지능적이거나 구조화된 방식으로 처리하는 방법을 모르겠습니다. 시작 후 작성된 모든 파일을 확인하는 명령을 몇 가지 찾았지만 일주일에 수동으로 확인하기에는 너무 많습니다.
드라이브가 계속 읽기 전용 모드로 전환되는 이유는 아직 확실하지 않지만 이는 별도의 문제일 수 있습니다.
어떤 도움이라도 대단히 감사하겠습니다!
smartctl 7.1 2019-12-30 r5022 [x86_64-linux-5.4.0-40-generic] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Number: KINGSTON SA2000M8500G
Serial Number: XXXX
Firmware Version: S5Z42105
PCI Vendor/Subsystem ID: 0x2646
IEEE OUI Identifier: 0x0026b7
Controller ID: 1
Number of Namespaces: 1
Namespace 1 Size/Capacity: 500,107,862,016 [500 GB]
Namespace 1 Utilization: 29,767,180,288 [29.7 GB]
Namespace 1 Formatted LBA Size: 512
Namespace 1 IEEE EUI-64: 0026b7 282536db15
Local Time is: Wed Jul 15 19:53:03 2020 CEST
Firmware Updates (0x14): 2 Slots, no Reset required
Optional Admin Commands (0x0017): Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005f): Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Maximum Data Transfer Size: 32 Pages
Warning Comp. Temp. Threshold: 75 Celsius
Critical Comp. Temp. Threshold: 80 Celsius
Supported Power States
St Op Max Active Idle RL RT WL WT Ent_Lat Ex_Lat
0 + 9.00W - - 0 0 0 0 0 0
1 + 4.60W - - 1 1 1 1 0 0
2 + 3.80W - - 2 2 2 2 0 0
3 - 0.0450W - - 3 3 3 3 2000 2000
4 - 0.0040W - - 4 4 4 4 15000 15000
Supported LBA Sizes (NSID 0x1)
Id Fmt Data Metadt Rel_Perf
0 + 512 0 0
=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
SMART/Health Information (NVMe Log 0x02)
Critical Warning: 0x00
Temperature: 46 Celsius
Available Spare: 100%
Available Spare Threshold: 10%
Percentage Used: 10%
Data Units Read: 12,031,713 [6.16 TB]
Data Units Written: 110,463,016 [56.5 TB]
Host Read Commands: 248,933,785
Host Write Commands: 1,467,111,619
Controller Busy Time: 9,524
Power Cycles: 101
Power On Hours: 4,515
Unsafe Shutdowns: 5
Media and Data Integrity Errors: 0
Error Information Log Entries: 0
Warning Comp. Temperature Time: 0
Critical Comp. Temperature Time: 0
Error Information (NVMe Log 0x01, max 256 entries)
No Errors Logged
답변1
동료들의 피드백을 바탕으로 범인을 찾아냈습니다. 이 문제는 Duplicati가 임시 파일을 작성하고 삭제하면서 발생한 것으로 밝혀졌습니다. 이 문제를 해결하기 위해 해당 파일의 위치를 SSD 대신 하드 드라이브로 변경했습니다.