Czy zły sektor wskazuje na awarię dysku?

Mój system Ubuntu 13.10 działał bardzo słabo w ciągu ostatniego dnia. Patrząc na dzienniki jądra, okazuje się, że <1-letni dysk SATA o pojemności 3 TB ma problemy z określonym sektorem:

Nov  4 20:54:04 mediaserver kernel: [10893.039180] ata4.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Nov  4 20:54:04 mediaserver kernel: [10893.039187] ata4.01: BMDMA stat 0x65
Nov  4 20:54:04 mediaserver kernel: [10893.039193] ata4.01: failed command: READ DMA EXT
Nov  4 20:54:04 mediaserver kernel: [10893.039202] ata4.01: cmd 25/00:08:f8:3f:83/00:00:af:00:00/f0 tag 0 dma 4096 in
Nov  4 20:54:04 mediaserver kernel: [10893.039202]          res 51/40:00:f8:3f:83/40:00:af:00:00/10 Emask 0x9 (media error)
Nov  4 20:54:04 mediaserver kernel: [10893.039207] ata4.01: status: { DRDY ERR }
Nov  4 20:54:04 mediaserver kernel: [10893.039211] ata4.01: error: { UNC }
Nov  4 20:54:04 mediaserver kernel: [10893.148527] ata4.00: configured for UDMA/133
Nov  4 20:54:04 mediaserver kernel: [10893.180322] ata4.01: configured for UDMA/133
Nov  4 20:54:04 mediaserver kernel: [10893.180345] sd 3:0:1:0: [sdc] Unhandled sense code
Nov  4 20:54:04 mediaserver kernel: [10893.180349] sd 3:0:1:0: [sdc]
Nov  4 20:54:04 mediaserver kernel: [10893.180353] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Nov  4 20:54:04 mediaserver kernel: [10893.180356] sd 3:0:1:0: [sdc]
Nov  4 20:54:04 mediaserver kernel: [10893.180359] Sense Key : Medium Error [current] [descriptor]
Nov  4 20:54:04 mediaserver kernel: [10893.180371] Descriptor sense data with sense descriptors (in hex):
Nov  4 20:54:04 mediaserver kernel: [10893.180373]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
Nov  4 20:54:04 mediaserver kernel: [10893.180384]         af 83 3f f8
Nov  4 20:54:04 mediaserver kernel: [10893.180389] sd 3:0:1:0: [sdc]
Nov  4 20:54:04 mediaserver kernel: [10893.180393] Add. Sense: Unrecovered read error - auto reallocate failed
Nov  4 20:54:04 mediaserver kernel: [10893.180396] sd 3:0:1:0: [sdc] CDB:
Nov  4 20:54:04 mediaserver kernel: [10893.180398] Read(16): 88 00 00 00 00 00 af 83 3f f8 00 00 00 08 00 00
Nov  4 20:54:04 mediaserver kernel: [10893.180412] end_request: I/O error, dev sdc, sector 2944614392
Nov  4 20:54:04 mediaserver kernel: [10893.180431] ata4: EH complete

kern.logPlik jest około 33MB głównie pełne powyższego błędu wielokrotnym i sektor nie wydaje się być inny w powtarzających się komunikatów.

Obecnie uruchamiam następujące polecenie na odmontowanym dysku, aby przetestować i spróbować rozwiązać problemy, które mogą wystąpić na dysku. Mam około 12 godzin i oczekuję, że zajmie to kolejne 24/48 godzin, ponieważ dysk jest tak duży:

e2fsck -c -c -p -v /dev/sdc1

Moje pytanie brzmi: czy ten dysk nie działa, czy też szukam tutaj typowego problemu? Zastanawiam się, czy nie ma sensu naprawiać lub ignorować uszkodzonych sektorów i czy powinienem wymienić dysk w ramach gwarancji, dopóki jest objęty gwarancją. Trochę brakuje mi wiedzy na temat powyższego polecenia, więc jestem sceptyczny, czy to pomoże, czy nie.

Szybka aktualizacja!

e2fsck ostatecznie zakończył się po 2 dniach z dużą ilością „bloków o wielu roszczeniach w inode”. Próba zamontowania systemu plików spowodowała błąd, zmuszając go do powrotu do trybu tylko do odczytu:

Nov 11 08:29:05 mediaserver kernel: [211822.287758] EXT4-fs (sdc1): warning: mounting fs with errors, running e2fsck is recommended
Nov 11 08:29:05 mediaserver kernel: [211822.301699] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: errors=remount-ro

Próba ręcznego odczytania sektora:

sudo dd count=1 if=/dev/sdc of=/dev/null skip=2944614392
dd: reading ‘/dev/sdc’: Input/output error
0+0 records in
0+0 records out
0 bytes (0 B) copied, 5.73077 s, 0.0 kB/s

Próbuję do tego napisać:

sudo dd count=1 if=/dev/zero of=/dev/sdc seek=2944614392
dd: writing to ‘/dev/sdc’: Input/output error
1+0 records in
0+0 records out
0 bytes (0 B) copied, 2.87869 s, 0.0 kB/s

W obu przypadkach Reallocated_Sector_Ctpozostałe 0.

Dysk dość często przechodzi w stan uśpienia. Teraz myślę, że może to być problem z systemem plików? Nie jestem w 100%.

Uszkodzone sektory zawsze wskazują na awarię dysku twardego, w rzeczywistości w momencie, gdy zobaczysz błąd we / wy, taki jak ten, prawdopodobnie już straciłeś / uszkodziłeś niektóre dane. Wykonaj kopię zapasową, jeśli jeszcze jej nie masz, uruchom autotest smartctl -t long /dev/diski sprawdź dane SMART smartctl -a /dev/disk. Zdobądź zamiennik, jeśli możesz.

Uszkodzonych sektorów nie można naprawić, zastępuje się je tylko sektorami rezerwowymi, co szkodzi wydajności dysku twardego, ponieważ wymagają one dodatkowych poszukiwań w sektorach rezerwowych za każdym razem, gdy są dostępne. Oznaczanie takich sektorów jako złych w warstwie systemu plików pomaga, ponieważ nigdy nie będą one dostępne; jednak trudno jest ustalić, które sektory zostały już ponownie przydzielone przez dysk, więc istnieje prawdopodobieństwo, że system plików nie będzie wiedział, jak uniknąć dotkniętego regionu.

Aby skłonić do realokacji sektorów, zwykle musisz coś do nich napisać. Jednak dd( D isk D estroyer) nie zawsze działa i jest bardzo niebezpieczne: jeśli mylić skipi seekopcji, można łatwo strzelać sobie w stopę przez skipping z Npierwszych bloków /dev/zeroi pisanie blok od tego „offset” nad sektor 0 twojego dysku twardego .

Jeśli naprawdę wiesz, że chcesz wymusić nadpisanie sektora zerami, powinieneś użyć hdparm:

% sudo hdparm --read-sector 833192656 /dev/sda
/dev/sda:
reading sector 833192656: FAILED: Input/output error

Tak, sektor 833192656 również zawiódł w inteligentnych testach. Aby zapisać do niego zera, użyj --write-sector:

% sudo hdparm --write-sector 833192656 /dev/sda
/dev/sda:
Use of --write-sector is VERY DANGEROUS.
You are trying to deliberately overwrite a low-level sector on the media.
This is a BAD idea, and can easily result in total data loss.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this.
Program aborted.

Jako zabezpieczenie, hdparmtak naprawdę nic nie pisze, chyba że --yes-i-know-what-i-am-doingprzełączysz przełącznik na hdparm:

% sudo hdparm --yes-i-know-what-i-am-doing --write-sector 833192656 /dev/sda
/dev/sda:
re-writing sector 833192656: succeeded
% sudo hdparm --read-sector 833192656 /dev/sda                              

/dev/sda:
reading sector 833192656: succeeded
0000 0000 0000 0000 0000 0000 0000 0000
[      ... more zeroes here...        ]
0000 0000 0000 0000 0000 0000 0000 0000

%

Nie, złe sektory nie zawsze są wskazują na awarię dysku. Czasami, jeśli zapis jest w trakcie awarii zasilania, dane w sektorze zostaną uszkodzone, co spowoduje błąd podczas próby jego odczytania. Próba zapisania nowych danych w sektorze może działać dobrze, ponieważ nie ma w tym nic fizycznego.

Możesz uruchomić badblocks -nna dysku, aby odczytać i przepisać każdy sektor, aw twoim przypadku, ponieważ znasz już numer danego sektora, możesz użyć dddo zapisania zer. Możesz sprawdzić statystyki SMART za pomocą smartctl -a. Powinieneś zobaczyć oczekującą realokację liczby wskazującą, ile sektorów nie udało się odczytać, a po próbie zapisu sektora liczba ta spadnie. Liczba przeniesionych sektorów może wzrosnąć, w takim przypadku był fizycznie zły i został przeniesiony do rezerwowej puli, a to może oznaczać, że dysk jest w drodze. Jeśli nie, to było po prostu zakodowane i powinno być teraz w porządku.

Spróbuj najpierw przeczytać sektor:

dd count=1 if=/dev/sda of=/dev/null skip=nnnn

Jeśli to się nie powiedzie, masz odpowiedni numer, możesz go wyzerować za pomocą:

dd count=1 if=/dev/zero of=/dev/sda seek=nnnn

Sprawdź dokładnie, czy wpisałeś polecenie dokładnie przed naciśnięciem klawisza Enter.