Ubuntu 18.04에서 오류로 인해 시스템이 내 루트 파티션(/dev/sda4)을 읽기 전용으로 무작위로 다시 마운트하는 하드 드라이브 문제가 발생했습니다.
dmesg|grep 'I/O error'sda4의 명백한 문제를 드러냅니다. 상자가 성공적으로 재부팅되었고 현재로서는 문제가 없기 때문에 지금은 정확한 출력이 없습니다.
내 계획은 파일 시스템에서 파일 시스템 검사를 실행하는 것이었습니다. 나는 팔로우했다이 답변게다가이 튜토리얼주의하여. 후자의 튜토리얼에서는 "라는 제목의 섹션을 사용했습니다.systemd를 사용할 때 Linux에서 시스템 재부팅 후 fsck가 파일 시스템을 확인하도록 강제하는 방법"
그러나 재부팅 후에는 다음 명령의 출력에서 알 수 있듯이 파일 시스템이 확인되지 않습니다.
tune2fs -l /dev/sda4 | grep checked
Last checked: Sat Nov 21 15:36:56 2020
GRUB CMDLINE의 다음 변형을 시도했지만 실패했습니다.
GRUB_CMDLINE_LINUX_DEFAULT="maybe-ubiquity fsck.mode=force"
그리고
GRUB_CMDLINE_LINUX_DEFAULT="maybe-ubiquity fsck.mode=force fsck.repair=yes"
그리고 네, 저는 뛰었습니다 update-grub. 내가 무엇을 놓치고 있나요?
출력 smartctl -a /dev/sda:
Device Model: Samsung SSD 860 EVO 250GB
Serial Number: S59WNG0MA22770K
LU WWN Device Id: 5 002538 e70265a2a
Firmware Version: RVT03B6Q
User Capacity: 250,059,350,016 bytes [250 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Form Factor: 2.5 inches
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: Unknown(0x09fc), ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Wed May 3 11:35:14 2023 MST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: ( 0) seconds.
Offline data collection
capabilities: (0x53) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
No Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 85) minutes.
SCT capabilities: (0x003d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 038 038 010 Pre-fail Always - 311
9 Power_On_Hours 0x0032 095 095 000 Old_age Always - 21420
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 14
177 Wear_Leveling_Count 0x0013 001 001 000 Pre-fail Always - 2041
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
183 Runtime_Bad_Block 0x0013 038 038 010 Pre-fail Always - 311
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0032 067 065 000 Old_age Always - 33
195 Hardware_ECC_Recovered 0x001a 200 200 000 Old_age Always - 0
199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0
235 Unknown_Attribute 0x0012 099 099 000 Old_age Always - 10
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 166281511800
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
256 0 65535 Read_scanning was never started
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
업데이트:
오늘 아침에 서버가 다시 충돌했습니다(아직 작동 중이지만 /읽기 전용으로 마운트되어 있음). dmesg에서 본 내용은 다음과 같습니다.
dmesg |grep sda
[70547.166349] sd 0:0:0:0: [sda] tag#13 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[70547.166354] sd 0:0:0:0: [sda] tag#13 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00
[70948.441912] sd 0:0:0:0: [sda] tag#15 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[70948.441918] sd 0:0:0:0: [sda] tag#15 CDB: Read(10) 28 00 1a cb 1c 00 00 00 08 00
[70948.441922] print_req_error: I/O error, dev sda, sector 449518592
[70948.442312] sd 0:0:0:0: [sda] tag#16 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[70948.442315] sd 0:0:0:0: [sda] tag#16 CDB: Read(10) 28 00 1a cb 1c 00 00 00 08 00
[70948.442316] print_req_error: I/O error, dev sda, sector 449518592
[70948.442955] sd 0:0:0:0: [sda] tag#17 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[70948.442960] sd 0:0:0:0: [sda] tag#17 CDB: Read(10) 28 00 0e 0b 03 08 00 00 20 00
[70948.442962] print_req_error: I/O error, dev sda, sector 235602696
[70948.443389] sd 0:0:0:0: [sda] tag#18 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[70948.443393] sd 0:0:0:0: [sda] tag#18 CDB: Read(10) 28 00 0e 0b 03 08 00 00 08 00
[70948.443396] print_req_error: I/O error, dev sda, sector 235602696
[72347.211525] sd 0:0:0:0: [sda] tag#19 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[72347.211531] sd 0:0:0:0: [sda] tag#19 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00
[74147.255746] sd 0:0:0:0: [sda] tag#21 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[74147.255752] sd 0:0:0:0: [sda] tag#21 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00
[75947.299631] sd 0:0:0:0: [sda] tag#23 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[75947.299637] sd 0:0:0:0: [sda] tag#23 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00
[77747.345291] sd 0:0:0:0: [sda] tag#25 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[77747.345297] sd 0:0:0:0: [sda] tag#25 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00
[79547.389376] sd 0:0:0:0: [sda] tag#27 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[79547.389382] sd 0:0:0:0: [sda] tag#27 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00
[81347.432593] sd 0:0:0:0: [sda] tag#29 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
[81347.432598] sd 0:0:0:0: [sda] tag#29 CDB: ATA command pass through(16) 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00
드라이브를 교체해야 한다는 것을 알고 있지만 내 목표는 단순히 fsck루트 파티션에서 실행하는 것입니다.
답변1
시도 중인 솔루션을 사용하여 fsck를 강제 실행하는 방법을 모르겠지만 대체 솔루션을 제안할 수 있습니다.
tune2fs값을 매우 낮은 재마운트 및 매우 낮은 타임스탬프로 사용 하고 제한합니다.
# To see current settings
sudo tune2fs -l /dev/sda4
# To alter it
sudo tune2fs -c 1 -i 1d /dev/sda4
이렇게 하면 1번 다시 마운트할 때마다 또는 마지막 확인 이후 1일마다 확인이 강제로 수행됩니다.
스마트 확인
다른 사람들이 말했듯이 이것은 HW 문제에 대한 반창고일 뿐입니다. 때때로 HDD가 죽거나, 다른 경우에는 관련 없는 HW 문제이거나(memtest 수행), 다른 경우에는 느슨한 SATA 케이블일 뿐입니다(양쪽 끝에서 뽑았다가 다시 꽂아도 문제가 해결되지 않으면 다른 케이블을 사용해 보십시오). .
PSU가 오작동하고 나머지 HW를 손상시키는 최악의 시나리오에 주의하십시오(이 경우 시간이 지남에 따라 새 HDD가 PSU에 의해 손상되므로 HDD를 교체하면 문제가 일시적으로만 해결됩니다). 전압이 허용 가능한 수준 내에 있는지 확인하십시오.
스마트 출력 게시:
sudo smartctl -a /dev/sda
무슨 일이 일어나고 있는지 진단하는 데 도움이 될 수 있습니다.
업데이트
tune2fs를 통해 fsck를 실행할 수 없는 이유도 모르겠습니다.
그런데 당신의 SMART를 봤어요. 그에 따르면 디스크가 노화되고 있지만 건강한 것 같습니다.
SATA 케이블과 같은 다른 곳에 문제가 있을 수 있습니다.
fsck가 작동하도록 할 수 없는 경우 제가 제안할 수 있는 것은 liveUsb에서 부팅하고 명령을 직접 실행하는 것뿐입니다.
업데이트 2
좋습니다. dmseg 메시지를 게시하셨습니다.SMART와 OS에서 나오는 정보가 상충됩니다., 그래서 자세히 쓰겠습니다.
불량 블록
SMART는 드라이브에 불량 블록이 있다고 말합니다. SSD가 오래됨에 따라 이는 정상적인 현상입니다., 드라이브는 데이터를 예비 블록에 재할당합니다. 여유 공간이 부족해지면 드라이브를 교체해야 합니다.
SMART는 불량 블록의 양이 "정상" 범위 내에 있다고 말합니다.: 여기서 볼 수 있는 가장 중요한 속성은 Reallocated_Sector_Ct및 입니다 Runtime_Bad_Block.
311개의 불량 블록을 감지하고 311개를 예비로 재할당했다고 합니다. 이것은 좋다. 311개의 불량 블록이 있었지만 재할당이 310개만 있었다면 이는 블록 중 하나의 데이터가 손실되었음을 의미합니다.
중요한 것은 "정규화된" 값(038)입니다. 이것이 제조업체가 정상이라고 생각하는 것을 알려주는 방법입니다.
100은 완벽함을 의미하고 0은 매우 나쁨을 의미하는 값입니다. 지금은 "이것이 점점 나빠지고 있다"고 말하는 38입니다. 하지만 제조업체에서는 해당 값이 010(THRESHold) 이상이면 괜찮다고 말합니다.
여기에 첫 번째 상충되는 정보가 있습니다.Used_Rsvd_Blk_Cnt_Tot 보호 구역이 전혀 건드리지 않았다고 말합니다., 불량 블록이 있음에도 불구하고. 합산되지 않습니다.
그러나 보고에도 불구하고 펌웨어가 이 값을 추적하지 않더라도 놀라지 않을 것이므로 지금은 이를 무시하겠습니다.
웨어 레벨링
이것은 읽기에 가장 문제가 되는 속성입니다. Wear_Leveling_Count001이라고 말합니다. 일반적으로 값이 1이면 드라이브가 작동하지 않으며 최대한 빨리 교체해야 함을 의미합니다.
이는 예비 블록이 부족하다는 것을 의미합니다. 그러나 이 속성이 거꾸로 보고되는 펌웨어 버그가 있었고 값이 1이면 드라이브 상태가 99%임을 의미합니다.
사용하여TBW 계산기작성된 LBA 수 + 512 섹터 크기를 삽입했는데 드라이브에 77.43TiB가 기록된 것으로 나타났습니다. Google에 따르면 귀하의 모델에는 150TBW가 있어야 하므로~해야 한다아직 실행 가능합니다.
여기서 가장 좋은 해결책은 Windows 상자를 가동하고 실행하는 것입니다.CrystalDiskInfo내부 데이터베이스를 사용하여 이러한 펌웨어 버그를 설명하고 매우 정확한 상태 평가를 보고합니다.
SMART overall-health self-assessment test result: PASSED당신의 똑똑한 사람 이 1% 대신 99%를 말하고 싶다고 믿고 있다고 말하는 것을 고려하면 .
하지만 제가 틀렸다면 여기서 멈추면 됩니다. 디스크를 교체해야 합니다.
케이블 문제 / 마더보드 문제
Linux dmesg의 오류는 기본적으로 섹터를 읽으려고 시도했지만 잘못된 데이터를 얻었음을 나타냅니다.
커널은 심지어 섹터 235602696을 두 번 읽으려고 시도했지만 다른 데이터를 얻었다고 말합니다.
- 28 00 0e 0b 03 08 00 002000
- 28 00 0e 0b 03 08 00 000800.
디스크에는 오류가 없다고 표시되지만 OS에는 오류가 있다고 표시되는 경우; 그런 다음 전송 중에 데이터가 손상되었습니다. 일반적으로 이는 다음을 나타냅니다.
- SATA 케이블이 느슨하게 연결되어 있습니다.
- SATA 케이블이 손상되었습니다
- 전원 케이블이 느슨하게 연결되어 있음
- 전원 케이블이 손상됨
- 마더보드 버스 오류
- PSU 오류
- RAM 오류
하지만 여기에 우리가 있는 곳이 있어요상충되는 정보의 두 번째 출처: UDMA_CRC_Error_Count0입니다.
이는 디스크가 불량/느슨한 케이블 또는 불량 마더보드 버스로 인해 발생한 단일 오류를 감지하지 못했음을 의미합니다.
이것은 거의 불가능합니다. SMART는 디스크가 양호하며 OS에서 디스크로 도착하는 명령이 잘못된 배선으로 인해 손상되지 않는다고 말합니다. 그러나 OS는 동일한 섹터를 두 번 읽고 다른 바이트를 얻었습니다.
내가 이것을 가능하게 할 것이라고 생각할 수 있는 유일한 것은 RAM이 좋지 않은 경우입니다.또는 디스크에 들어가는 모든 데이터는 절대 손상되지 않지만 디스크에서 나가는 데이터는 손상되는 극히 드문 케이블 문제입니다.
행동의 과정
내 직감은 디스크가 나쁘다고 말합니다. 하지만:
- 모든 데이터를 다른 디스크에 백업하세요. LiveUSB 실행(및 충분히 큰 외부 USB 드라이브):
sudo apt install zstd
# To backup
sudo zstd -16v < /dev/sda > /media/external_disk/backup_file.zst
# To restore (don't do that on step 1, see step 5)
sudo zstdcat -v /media/external_disk/backup_file.zst > /dev/sda
- 데이터를 다시 백업하되 이번에는 일반 복사본 파일만 사용합니다. (디스크가 죽으면 디스크의 압축된 zstd 이미지를 루프 마운트하고 거기에서 파일을 읽는 것보다 간단한 백업에서 복구하는 것이 훨씬 쉽습니다.)
- RAM 오류를 삭제하려면 재부팅하고 memtest를 실행하세요.
- 종료하고 케이스를 연 다음 SATA 및 전원(드라이브용) 케이블을 뽑았다가 다시 연결합니다. 손상되지 않았는지 확인하세요. 교체할 수도 있습니다.
- LiveUSB 드라이브를 다시 부팅하고 디스크를 안전하게 삭제합니다. 드라이브에 버그가 발생하면 작동 상태로 다시 재설정될 수 있습니다(또는 디스크가 복구할 수 없는 경우 마지막 명령이 실행될 수도 있습니다). 이 작업은 몇 분 정도 걸립니다.
sudo blkdiscard -s /dev/sda
- 지금까지 문제가 해결되지 않았다면
sudo zstdcat1단계의 명령을 사용하여 백업을 복원하세요.
디스크에 여전히 문제가 있고 memtest가 성공했다면 개인적으로 디스크가 불량하다고 판단합니다.
Reallocated_Sector_Ct제조업체가 아직 "그렇게" 나쁘지는 않다고 말했음에도 불구하고 값 038은 상황이 점점 나빠지고 있음을 의미한다는 점을 무시할 수 없습니다 .
아! 중요: 어떤 시점에서 디스크를 꺼진 상태로 3개월 이상 방치한 경우; 이 시나리오는 충분히 가능합니다. 대중적인 믿음에도 불구하고 NAND 셀은 너무 오랫동안 전원을 공급받지 않은 채 방치하면 저장 공간을 잃을 수 있습니다("너무 긴" 기간은 7일에서 7년까지일 수 있지만 가장 일반적인 경우는 3개월입니다). 특히 나이가 많은 경우에는 더욱 그렇습니다.
이런 일이 발생한 경우 위의 단계를 수행하십시오. 데이터 백업, 디스크 보안 삭제, 백업 복원.
행운을 빌어요.