Próba usunięcia / zdiagnozowania pojedynczego sektora Current_Pending_Sector w danych SMART

18

Robię świeżą instalację Linuksa i zanim to zrobiłem, pomyślałem, że to dobry czas na sprawdzenie stanu dysku twardego, ponieważ w razie potrzeby mogę bezpiecznie zastąpić dowolne dane na dysku twardym.

Najpierw próbowałem sprawdzić za pomocą smartmontools ... Mój dysk twardy Seagate zgłasza jeden bieżący sektor w toku i jeden niedziałający w trybie offline (prawdopodobnie ten sam). Liczba przydzielonych sektorów wynosi zero.

5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
...
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       1

Jednak autotesty SMART (krótkie, długie, offline, transport) nie znajdują błędów. 

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      6631         -
# 2  Conveyance offline  Completed without error       00%      6630         -
# 3  Extended offline    Completed without error       00%      6622         -
# 4  Short offline       Completed without error       00%      6600         -
# 5  Extended offline    Completed without error       00%      6632         -

Próbowałem także uruchomić na dysku dysk badblocks -wsv (pełny test 4 odczytu i zapisu) i nie znaleziono żadnych uszkodzonych bloków. Następnie postępowałem zgodnie z instrukcjami (w możliwym zakresie, ponieważ usunąłem system plików po uruchomieniu Badblocks), które można znaleźć tutaj: http://smartmontools.sourceforge.net/badblockhowto.html

Tam napisano, że jeśli zastąpię sektor wszystkimi zerami, dysk powinien przenieść (ponownie przydzielić) sektor oczekujący. Wzorzec ostatniego zapisu Badblocks zawiera wszystkie zera, więc powinienem to zrobić. jednak nic się nie zmieniło Nadal mam tę oczekującą liczbę sektorów 1.
Próbowałem dowiedzieć się, który sektor jest problematyczny, a na wyjściu SMART znajduje się dziennik błędów:

Error 2 occurred at disk power-on lifetime: 5344 hours (222 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 7c 1b 1a 02 ae  Error: ABRT at LBA = 0x0e021a1b = 235018779

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  20 20 7f 18 1a 02 ae 00      00:09:05.228  READ SECTOR(S)
  20 20 01 17 1a 02 ae 00      00:09:05.228  READ SECTOR(S)
  20 20 01 01 00 00 a0 00      00:08:59.830  READ SECTOR(S)
  91 20 3f 01 00 00 af 00      00:08:59.826  INITIALIZE DEVICE PARAMETERS [OBS-6]
  10 20 01 01 00 00 a8 00      00:08:59.678  RECALIBRATE [OBS-4]

Error 1 occurred at disk power-on lifetime: 5009 hours (208 days + 17 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 b7 8c 02 e0  Error: UNC at LBA = 0x00028cb7 = 167095

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 20 1e 9e 8c 02 e0 00      00:02:20.691  READ DMA EXT
  25 20 1e 80 8c 02 e0 00      00:02:20.691  READ DMA EXT
  25 20 1e 62 8c 02 e0 00      00:02:20.690  READ DMA EXT
  25 20 1e 44 8c 02 e0 00      00:02:20.690  READ DMA EXT
  25 20 1e 26 8c 02 e0 00      00:02:20.690  READ DMA EXT

Najwyraźniej na dysku wystąpiły dwa błędy.

84 51 7c 1b 1a 02 ae  Error: ABRT at LBA = 0x0e021a1b = 235018779

i

40 51 00 b7 8c 02 e0  Error: UNC at LBA = 0x00028cb7 = 167095

Więc założyłem, że są to numery sektorów: 167095 i 235018779. Próbowałem pisać zera za pomocą dd:

dd if=/dev/zero of=/dev/sda bs=512 count=1 seek=167095

Teraz było dobrze. Jednak gdy próbowałem z innym sektorem:

dd if=/dev/zero of=/dev/sda bs=512 count=1 seek=235018779

Dostaję dd: '/ dev / sda': nie można szukać: niepoprawny argument . Następnie zauważyłem, że mój dysk twardy ma tylko 234441658 sektorów. To jest poza zasięgiem. Ale dlaczego SMART zgłosił błąd pod tym adresem ?!

Czy ktoś może mi pomóc to rozgryźć, a także doradzić, jak to zrobić poprawnie, jeśli robię to źle? Podejrzewam, że może mylę się przy użyciu bloku 512 z dd. To jest wielkość sektora zgłaszana przez SMART. może te adresy LBA to bajty, a nie bloki Próbowałem ustawić bs = 1 i zapisać tylko jeden bajt do tych adresów na dysku twardym. To działało (proces zapisu dd)… Jednak liczba oczekujących sektorów wciąż się nie zmieniała. Zadzwoniłem także do sync i smartctl -t offline / dev / sda, aby spróbować „wymusić” napęd w celu realokacji sektora. Nic...

Oto moje pełne wyjście smartctl --all / dev / sda :

smartctl 5.43 2012-06-30 r3573 [i686-linux-2.6.32-358.el6.i686] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Barracuda 7200.9
Device Model:     ST3120811AS
Serial Number:    6PT1N4VZ
Firmware Version: 3.AAE
User Capacity:    120,034,123,776 bytes [120 GB]
Sector Size:      512 bytes logical/physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Mon Nov 18 12:03:00 2013 UTC
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:  (0x82) Offline data collection activity
                    was completed without error.
                    Auto Offline Data Collection: Enabled.
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:        (  430) seconds.
Offline data collection
capabilities:            (0x5b) SMART execute Offline immediate.
                    Auto Offline data collection on/off support.
                    Suspend Offline collection upon new
                    command.
                    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:    (   1) minutes.
Extended self-test routine
recommended polling time:    (  51) minutes.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   084   077   006    Pre-fail  Always       -       185600113
  3 Spin_Up_Time            0x0003   095   095   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   098   098   020    Old_age   Always       -       2185
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   073   055   030    Pre-fail  Always       -       25890559714
  9 Power_On_Hours          0x0032   093   093   000    Old_age   Always       -       6632
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   098   098   020    Old_age   Always       -       2229
187 Reported_Uncorrect      0x0032   099   099   000    Old_age   Always       -       1
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   071   056   045    Old_age   Always       -       29 (Min/Max 25/29)
194 Temperature_Celsius     0x0022   029   044   000    Old_age   Always       -       29 (0 13 0 0 0)
195 Hardware_ECC_Recovered  0x001a   052   046   000    Old_age   Always       -       194244099
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       1
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0000   100   253   000    Old_age   Offline      -       0
202 Data_Address_Mark_Errs  0x0032   066   219   000    Old_age   Always       -       34

SMART Error Log Version: 1
ATA Error Count: 2
    CR = Command Register [HEX]
    FR = Features Register [HEX]
    SC = Sector Count Register [HEX]
    SN = Sector Number Register [HEX]
    CL = Cylinder Low Register [HEX]
    CH = Cylinder High Register [HEX]
    DH = Device/Head Register [HEX]
    DC = Device Command Register [HEX]
    ER = Error register [HEX]
    ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 2 occurred at disk power-on lifetime: 5344 hours (222 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 7c 1b 1a 02 ae  Error: ABRT at LBA = 0x0e021a1b = 235018779

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  20 20 7f 18 1a 02 ae 00      00:09:05.228  READ SECTOR(S)
  20 20 01 17 1a 02 ae 00      00:09:05.228  READ SECTOR(S)
  20 20 01 01 00 00 a0 00      00:08:59.830  READ SECTOR(S)
  91 20 3f 01 00 00 af 00      00:08:59.826  INITIALIZE DEVICE PARAMETERS [OBS-6]
  10 20 01 01 00 00 a8 00      00:08:59.678  RECALIBRATE [OBS-4]

Error 1 occurred at disk power-on lifetime: 5009 hours (208 days + 17 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 b7 8c 02 e0  Error: UNC at LBA = 0x00028cb7 = 167095

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 20 1e 9e 8c 02 e0 00      00:02:20.691  READ DMA EXT
  25 20 1e 80 8c 02 e0 00      00:02:20.691  READ DMA EXT
  25 20 1e 62 8c 02 e0 00      00:02:20.690  READ DMA EXT
  25 20 1e 44 8c 02 e0 00      00:02:20.690  READ DMA EXT
  25 20 1e 26 8c 02 e0 00      00:02:20.690  READ DMA EXT

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      6631         -
# 2  Conveyance offline  Completed without error       00%      6630         -
# 3  Extended offline    Completed without error       00%      6622         -
# 4  Short offline       Completed without error       00%      6600         -
# 5  Extended offline    Completed without error       00%      6632         -

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
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.

AKTUALIZACJA:

Jak sugeruje odpowiedź Roba, próbowałem zastąpić cały dysk twardy zerami. Sprawdziłem wartości SMART, a następnie zacząłem czytać cały dysk twardy. Ponownie sprawdzone wartości SMART. Rezultat jest następujący: Wartości SMART dotyczące liczby oczekujących / realokowanych sektorów nie zmieniają się, w obu przypadkach, natychmiast po zapisie, a następnie po odczycie. Realocated 0. Oczekuje 1.

linux  hard-drive  smart  bad-sectors  bad-blocks 
— Ivan Kovacevic
źródło
1
Wydaje mi się, że twój dysk ma 234441658 sektorów, ale sektory kopii zapasowych zamapowane w miejsce uszkodzonych sektorów nie liczą się do tej liczby.
— gronostaj
Hmm, więc błąd w sektorze 235018779 oznaczałby błąd w sektorach kopii zapasowych… Czy to możliwe?
— Ivan Kovacevic,
1
Sektory zapasowe również mogą być uszkodzone. W przeciwnym razie zrobilibyśmy „nieśmiertelne” dyski twarde tylko z sektorów zapasowych.
— gronostaj
:)… Cóż, moje rozumowanie było takie, że sektory tworzenia kopii zapasowych nie są używane (i dlatego są bezpieczne). Przypuszczałem, że powierzchnia dysku twardego może ulec uszkodzeniu tylko wtedy, gdy głowice dysku powodują niewłaściwe działanie z powodu awarii zasilania lub czegoś innego.
— Ivan Kovacevic
1
Zakładając, że sektor 235018779 jest sektorem zapasowym. Oznacza to, że powinienem mieć co najmniej 235018779 - 234441658 = 577121 sektorów zapasowych. To prawie 282 MB w sektorach kopii zapasowych. Wydaje mi się (za dużo) dla mnie. Albo to jest? Po prostu myśląc głośno, może nie jest to sektor zapasowy, ale usterka w diagnostyce SMART?
— Ivan Kovacevic,

Odpowiedzi:

15

Sektor jest oznaczony jako oczekujący, gdy odczyt się nie powiedzie. Oczekujący sektor zostanie oznaczony ponownie przydzielony, jeśli kolejny zapis nie powiedzie się. Jeśli zapis się powiedzie, zostanie usunięty z bieżących sektorów oczekujących i zakłada się, że jest w porządku. (Dokładne zachowanie może się nieco różnić i przejdę do tego później, ale na razie jest to wystarczająco przybliżone przybliżenie).

Po uruchomieniu badblocks -wkażdy wzór jest najpierw zapisywany, a następnie czytany. Możliwe, że zapis do niestabilnego sektora się powiedzie, ale kolejny odczyt się nie powiedzie, co ponownie dodaje go do listy oczekujących sektorów. Próbowałbym zapisywać zera na całym dysku za pomocą dd if=/dev/zero of=/dev/sda, sprawdzając status SMART, a następnie czytając cały dysk za pomocą dd if=/dev/sda of=/dev/nulli ponownie sprawdzając status SMART.

Aktualizacja:

Na podstawie twoich wcześniejszych wyników z badblocks -w, oczekiwałbym, że oczekujący sektor zostanie wyczyszczony po zapisaniu całego dysku. Ale ponieważ tak się nie stało, można śmiało powiedzieć, że ten dysk nie działa zgodnie z oczekiwaniami.

Przyjrzyjmy się opisowi bieżącej liczby sektorów oczekujących :

Liczba „niestabilnych” sektorów (oczekujących na mapowanie z powodu niemożliwych do naprawienia błędów odczytu). Jeśli następnie niestabilny sektor zostanie pomyślnie odczytany, sektor jest ponownie mapowany i wartość ta jest zmniejszana. Błędy odczytu w sektorze nie powodują natychmiastowego ponownego mapowania sektora (ponieważ nie można odczytać poprawnej wartości, a zatem wartość do ponownego mapowania nie jest znana, a także może zostać odczytana później); zamiast tego oprogramowanie napędu pamięta, że ​​sektor musi zostać ponownie mapowany, i ponownie mapuje go przy następnym zapisie. [29] Jednak niektóre dyski nie będą natychmiast ponownie mapować takich sektorów po zapisaniu; zamiast tego dysk najpierw spróbuje zapisać do sektora problemowego, a jeśli operacja zapisu zakończy się powodzeniem, sektor zostanie oznaczony jako dobry (w tym przypadku „Liczba zdarzeń realokacji” (0xC4) nie zostanie zwiększona).

Teraz przejrzyjmy ważne punkty:

... oprogramowanie układowe napędu pamięta, że ​​sektor wymaga ponownego mapowania, i ponownie mapuje go przy następnym zapisie. [29] Jednak niektóre dyski nie będą natychmiast ponownie mapować takich sektorów po zapisaniu; zamiast tego dysk najpierw spróbuje zapisać do sektora problemowego, a jeśli operacja zapisu zakończy się powodzeniem, sektor zostanie oznaczony jako dobry.

Innymi słowy, oczekujący sektor powinien zostać albo natychmiast ponownie mapowany, albo dysk powinien spróbować zapisać się w sektorze i jedna z dwóch rzeczy powinna się wydarzyć:

  1. Zapis nie powiódł się, w którym to przypadku oczekujący sektor powinien zostać ponownie mapowany.
  2. Zapis powiódł się, w którym to przypadku oczekujący sektor powinien był zostać wyczyszczony („oznaczone jako dobre”).

Wspomniałem o tym wcześniej, ale opis Wikipedii dotyczący bieżącego sektora oczekującego sugeruje, że bieżąca liczba sektorów oczekujących powinna zawsze wynosić zero po pełnym zapisie dysku . Ponieważ tak nie jest w tym przypadku, możemy stwierdzić, że albo (a) Wikipedia jest niepoprawna (lub przynajmniej niepoprawna dla twojego dysku), albo (b) oprogramowanie wewnętrzne napędu nie może poprawnie obsłużyć tego stanu błędu (który uważam za błąd oprogramowania układowego ).

Jeśli następnie niestabilny sektor zostanie pomyślnie odczytany, sektor jest ponownie mapowany i wartość ta jest zmniejszana.

Ponieważ bieżąca liczba oczekujących sektorów pozostaje niezmieniona po odczytaniu całego dysku, możemy stwierdzić, że (a) sektor nie mógł zostać pomyślnie odczytany lub (b) sektor został pomyślnie odczytany i oznaczony jako dobry, ale wystąpił błąd podczas odczytu inny sektor. Ale ponieważ liczba ponownie przeniesionych sektorów po odczytaniu nadal wynosi 0, możemy wykluczyć (b) jako możliwość i możemy stwierdzić, że oczekujący sektor był nadal nieczytelny.

W tym momencie dobrze byłoby wiedzieć, czy dysk zarejestrował jakieś nowe błędy SMART. Moją następną sugestią było sprawdzenie, czy Seagate ma aktualizację oprogramowania układowego dla twojego dysku, ale wygląda na to, że nie.

Chociaż odradzam dalsze korzystanie z tego dysku, wygląda na to, że możesz zaakceptować związane z nim ryzyko (a mianowicie, że może on nadal działać nieprawidłowo i / lub może dalej degradować lub ulegać katastrofie). W takim przypadku możesz spróbować zainstalować Linuksa, uruchomić komputer z ratunkowej płyty CD, a następnie (przy odmontowanym systemie plików) użyj e2fsck -l nazwa pliku, aby ręcznie oznaczyć odpowiedni blok jako zły. (Tylko upewnij się, że masz dobre kopie zapasowe!)

e2fsck -l nazwa pliku

Dodaj numery bloków wymienione w pliku określonym przez nazwę pliku do listy uszkodzonych bloków. Format tego pliku jest taki sam, jak ten wygenerowany przez program badblocks (8). Należy pamiętać, że numery bloków są oparte na rozmiarze bloku systemu plików. Dlatego też badblocks (8) musi otrzymać blokowy rozmiar systemu plików, aby uzyskać prawidłowe wyniki. W rezultacie korzystanie z opcji -c w e2fsck jest znacznie prostsze i bezpieczniejsze, ponieważ zapewni, że prawidłowe parametry zostaną przekazane do programu badblocks.

(Zauważ, że e2fsck -cjest to preferowane e2fsck -l filename, a może nawet chcesz go wypróbować, ale w oparciu o dotychczasowe wyniki, bardzo wątpię, że e2fsck -c znajdzie jakieś złe bloki.)

Oczywiście będziesz musiał wykonać pewną arytmetykę, aby przekonwertować LBA wadliwego sektora (jak zapewnia SMART) na numer bloku systemu plików. Uszkodzonych bloków HowTo zapewnia poręczną formułę:

  b = (int)((L-S)*512/B)
where:
b = File System block number
B = File system block size in bytes
L = LBA of bad sector
S = Starting sector of partition as shown by fdisk -lu
and (int) denotes the integer part.

Poradnik zawiera również pełny przykład wykorzystujący tę formułę. Po zainstalowaniu systemu operacyjnego możesz potwierdzić, czy plik zajmuje niestabilny sektor, używając debugfs (szczegółowe instrukcje znajdują się w HowTo).

Inna opcja: partycja wokół podejrzewanego uszkodzonego bloku Podczas instalowania systemu operacyjnego można również spróbować podzielić partycję wokół błędu. Jeśli dobrze zrobiłem swoją arytmetykę, błąd wynosi około 81.589 MB, więc mogę albo zrobić / bootować trochę i rozpocząć następną partycję po sektorze 167095, albo całkowicie pominąć pierwsze 82 MB.

ABRT 235018779 Niestety, jeśli chodzi o błąd ABRT w sektorze 235018779, możemy jedynie spekulować, ale specyfikacja ATA8-ACS daje nam pewne wskazówki.

Z Roboczego Projektu AT Załącznik 8 - Zestaw poleceń ATA / ATAPI (ATA8-ACS) :

6.2.1 Przerwanie (ABRT) Bit błędu 2. Przerwanie należy ustawić na jeden, jeśli polecenie nie jest obsługiwane. Przerwanie można ustawić na jeden, jeśli urządzenie nie jest w stanie wykonać czynności wymaganej przez polecenie. Przerwanie należy również ustawić na jeden, jeżeli żądany jest adres spoza zakresu adresów dostępnych dla użytkownika, jeżeli IDNF nie jest ustawiony na jeden.

Patrząc na polecenia prowadzące do ABRT (kilka CZYTAJ SEKTOR (S), po których następuje ponowna kalibracja i ponowna inicjalizacja) ...

Przerwanie należy ustawić na jeden, jeśli polecenie nie jest obsługiwane. - Wydaje się to mało prawdopodobne.

Przerwanie można ustawić na jeden, jeśli urządzenie nie jest w stanie wykonać czynności wymaganej przez polecenie. - Być może lista P przeniesionych sektorów przesuwa adresy dostępne dla użytkownika na tyle, że adres dostępny dla użytkownika został przetłumaczony na sektor 235018779, a operacja odczytu nie mogła zostać zakończona (z jakiego powodu nie wiemy ... ale nie wystąpił błąd CRC, więc nie sądzę, abyśmy mogli stwierdzić, że sektor 235018779 jest zły).

Przerwanie należy również ustawić na jeden, jeżeli żądany jest adres spoza zakresu adresów dostępnych dla użytkownika, jeżeli IDNF nie jest ustawiony na jeden. - Wydaje mi się to najbardziej prawdopodobne i prawdopodobnie zinterpretowałbym to jako wynik błędu oprogramowania (systemu operacyjnego lub uruchomionego programu). W takim przypadku nie oznacza to zbliżającej się zagłady na dysku twardym.

Na wypadek, gdybyś nie miał już dość przeprowadzania diagnostyki ...

Możesz spróbować smartctl -t long /dev/sdajeszcze raz sprawdzić, czy powoduje więcej błędów w dzienniku SMART, lub pozostaw ten jako nierozwiązany plik X ;) i okresowo sprawdzaj dziennik SMART, aby zobaczyć, czy to się powtórzy. W każdym razie, jeśli będziesz nadal korzystać z dysku, nie zmuszając go do przeniesienia lub wyczyszczenia oczekującego sektora, już ryzykujesz.

Użyj systemu plików sumowania kontrolnego

Dla większego bezpieczeństwa możesz rozważyć użycie systemu plików sumowania kontrolnego, takiego jak ZFS lub btrfs, aby zabezpieczyć się przed uszkodzeniem danych na niskim poziomie. I nie zapomnij wykonywać częstych kopii zapasowych, jeśli masz coś, czego nie można łatwo odtworzyć.

— obrabować
źródło
Dobry pomysł, spróbuję teraz.
— Ivan Kovacevic
1
A może spróbujesz tego z tym złym sektorem 167095? :)
— tydzień
Naah, to zbyt nudne: D. Najpierw spróbuję z podejrzanym sektorem, zdecydowanie mądrą radą, jeśli to nic nie da, pozwolę mu działać na całym dysku na wszelki wypadek…
— Ivan Kovacevic
@ tydzień powinien to załatwić, ale wygląda na to, że ma problem z wyzerowaniem uszkodzonego sektora, dlatego zasugerowałem cały dysk.
— okradać
1
Jeśli po zapisaniu na całym dysku nadal występuje sektor oczekujący, wówczas mapowanie uszkodzonego sektora nie działa poprawnie i należy go wymienić (lub, jeśli jesteś graczem hazardowym, kontynuuj jego używanie, wiedząc, że może on zachowywać się nieprawidłowo) .
— rab
5

Artykuł Ponowne mapowanie sektora podaje zastosowany algorytm.

Na dysku twardym znajdują się dwie listy wad:

  • Lista P to wady wykryte podczas produkcji i są również znane jako wady pierwotne. Sekwencyjnie podążają za normalnymi sektorami. Zły sektor wskaże jego zastąpienie za pomocą numeru zmiany (najpierw +1, potem +2 itd.).
  • Lista G to wady, które rozwijają się podczas normalnego użytkowania dysku i są znane jako Wady Grown. Nie ma żadnych ograniczeń w ich alokacji i nie muszą oni sekwencyjnie śledzić wad listy P. Zły sektor wskaże na jego zastąpienie za pomocą prostego numeru sektora.

Dlatego fakt, że twój zły sektor jest o 577121 sektorów poza normalnym ostatnim sektorem, nie oznacza, że ​​masz 577121 złych sektorów, chyba że jest to defekt listy P. Wadę listy G można umieścić w dowolnym miejscu, więc jest całkiem możliwe, że oprogramowanie układowe przydzieliło ją na końcu wolnego miejsca w sektorze.

Z wikipedii Znane atrybuty ATA SMART :

Liczba realokowanych sektorów

Liczba przeniesionych sektorów. Gdy dysk twardy znajdzie błąd odczytu / zapisu / weryfikacji, oznacza ten sektor jako „ponownie przydzielony” i przesyła dane do specjalnego zarezerwowanego obszaru (obszar zapasowy). Ten proces jest również znany jako remapowanie, a przeniesione sektory nazywane są „remapami”. Surowa wartość zwykle reprezentuje liczbę uszkodzonych sektorów, które zostały znalezione i ponownie mapowane.

Obecna liczba oczekujących sektorów

Liczba „niestabilnych” sektorów (oczekujących na mapowanie z powodu niemożliwych do naprawienia błędów odczytu). Jeśli następnie niestabilny sektor zostanie pomyślnie odczytany, sektor jest ponownie mapowany i wartość ta jest zmniejszana. Błędy odczytu w sektorze nie powodują natychmiastowego ponownego mapowania sektora (ponieważ nie można odczytać poprawnej wartości, a zatem wartość do ponownego mapowania nie jest znana, a także może zostać odczytana później); zamiast tego oprogramowanie układowe napędu pamięta, że ​​sektor musi zostać ponownie mapowany, i ponownie mapuje go przy następnym zapisaniu.

W rzeczywistości oczekujące błędy są znacznie gorsze niż remapowane, ponieważ błąd jest wystarczająco twardy, aby uniemożliwić odczytanie oryginalnej zawartości w celu ponownego mapowania. W efekcie zawartość tego sektora prawdopodobnie zostanie utracona na zawsze.

Dokument MHDD Bardzo niski poziom narzędzia diagnostycznego dysku twardego wyjaśnia kody błędów jako: 

UNC : data is uncorrectable
ABRT : command was aborted

Sektor 167095 jest więc nie do naprawienia, a odczyt / zapis do 235018779 został przerwany.

Ponieważ pisanie do obu sektorów nie zmieniło statusu z oczekującego na remapowany, wydaje mi się, że sektor zastępczy jest również zły. Moja teoria jest taka, że ​​sektor 167095 został ponownie przypisany do sektora 235018779, ale niestety ten drugi jest również zły i że oprogramowanie układowe nie wie, jak zmienić mapowanie złych wolnych sektorów. Rezultatem jest niemożliwy do naprawienia zły sektor.

— harrymc
źródło
Niezły artykuł, na pewno nauczyłem się czegoś nowego! Jednak nadal nie wyjaśnia to, dlaczego zły sektor zgłoszony w dziennikach SMART jest nawet zgłaszany w obszarze sektora zapasowego, a nie w normalnej przestrzeni użytkowej i dlaczego licznik sektorów oczekujących nadal 1 i ponownie przypisał licznik sektorów 0. Jeśli wszystko działało tak, jak powinno te dwa liczniki powinny odwrócić ich wartości.
— Ivan Kovacevic,
1
Zobacz moją edycję powyżej.
— harrymc,
Dzięki! Świetna informacja! Teraz mam pytanie: skoro 167095 nie został ponownie mapowany, czy wskazane jest używanie tego dysku twardego? Czy HDD oznaczył ten sektor jako zły i uniknie go w przyszłości. Zasadniczo muszę zdecydować: czy mogę kontynuować i zainstalować system Linux, czy powinienem wyrzucić ten dysk twardy, kupić nowy i zainstalować system Linux, czy też mogę zrobić coś (wykonać polecenie), aby ręcznie oznaczyć ten sektor jako zły i zainstalować system Linux (mój ulubiona opcja).
— Ivan Kovacevic,
1
Duży dysk z tylko dwoma uszkodzonymi sektorami nie zasługuje na to, aby zostać śmieci. Jako że badblocks odniosły sukces, mam nadzieję, że oznaczało to ten sektor jako zły. Spróbowałbym zainstalować na nim Linuksa, ale wykonaj pełny format, jeśli Twoja dystrybucja może to zrobić podczas instalacji. Ale jeśli dotyczy to ważnego systemu produkcyjnego, na wszelki wypadek zmieniłbym dysk.
— harrymc,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.