Oczekiwany nieczytelny sektor to taki, który zwrócił błąd odczytu i który dysk oznaczył do ponownego mapowania przy pierwszej możliwej okazji. Nie można jednak wykonać ponownego mapowania, dopóki nie wydarzy się jedna z dwóch rzeczy:
- Sektor został ponownie odczytany
- Sektor został przepisany
Do tego czasu sektor pozostaje w toku. Masz więc dwa odpowiednie sposoby radzenia sobie z tym:
- Próbuj ponownie przeczytać sektor, dopóki nie odniesiesz sukcesu
- Zastąp ten sektor nowymi danymi
Oczywiście (1) nie jest destrukcyjny, więc prawdopodobnie powinieneś spróbować najpierw, chociaż pamiętaj, że jeśli dysk zaczyna poważnie zawodzić, to ciągłe czytanie ze złego obszaru prawdopodobnie spowoduje jego szybszą awarię . Jeśli masz wiele oczekujących sektorów i innych błędów i zależy Ci na danych na dysku, zalecamy wyłączenie go z użycia i użycie doskonałego narzędzia ddrescue do odzyskania jak największej liczby danych. Następnie wyrzuć dysk.
Jeśli dany sektor zawiera dane, na których Ci nie zależy, lub które można przywrócić z kopii zapasowej, zastąpienie go jest prawdopodobnie najszybszym i najprostszym rozwiązaniem. Następnie możesz wyświetlić ponownie przydzielone i oczekujące liczby dla dysku, aby upewnić się, że sektor został załatwiony.
Jak dowiedzieć się, co odpowiada sektorowi w systemie plików? Znalazłem doskonały artykuł na Smartmontools stronie internetowej, tutaj , choć to dość techniczny i jest specyficzny dla ext2 / 3/4 i plików Reiser systemów.
Prostszym podejściem, którego użyłem na jednym z moich własnych dysków (Mac), jest find / -xdev -type f -print0 | xargs -0 ...odczytanie każdego pliku w systemie. Zanotuj oczekującą liczbę przed uruchomieniem tego. Jeśli sektor znajduje się w pliku, otrzymasz komunikat o błędzie z narzędzia, którego użyłeś do odczytu plików (np. Md5sum), wskazujący ścieżkę do niego. Następnie możesz skoncentrować się na ponownym czytaniu tylko tego pliku, dopóki nie zostanie on pomyślnie odczytany. Często rozwiązuje to problem, jeśli jest to rzadko używany plik, który musiał zostać ponownie przeczytany kilka razy. Jeśli błąd zniknie lub nie wystąpią żadne błędy w odczycie wszystkich plików, sprawdź oczekującą liczbę, aby sprawdzić, czy zmniejszyła się. Jeśli tak, problem został rozwiązany przez czytanie.
Jeśli pliku nie można odczytać pomyślnie po wielu próbach (np. 20), musisz zastąpić plik lub blok w pliku, aby umożliwić przemieszczenie sektora przez dysk. Możesz użyć ddrescue na pliku (a nie na partycji), aby zastąpić tylko jeden sektor, kopiując do pliku tymczasowego, a następnie kopiując ponownie. Zauważ, że samo usunięcie pliku w tym momencie jest złym pomysłem, ponieważ zły sektor przejdzie na darmową listę, gdzie będzie trudniej go znaleźć. Całkowite nadpisanie go również jest złe, ponieważ sektory ponownie przejdą na darmową listę. Musisz przepisać istniejące bloki. notruncOpcja ddjest jednym ze sposobów, aby to zrobić.
Jeśli nie wystąpią żadne błędy, a liczba oczekujących operacji nie spadła, sektor musi znajdować się na liście swobodnej lub w części infrastruktury systemu plików (np. Tabela i-węzłów). Możesz spróbować wypełnić całe wolne miejsce cat /dev/zero >tempfile, a następnie sprawdzić liczbę oczekujących. Jeśli spadnie, problem znajdował się na liście darmowych i teraz zniknął.
Jeśli sektor znajduje się w infrastrukturze, masz poważniejszy problem i prawdopodobnie wystąpią błędy po prostu przechodząc przez drzewo katalogów. Myślę, że w tej sytuacji jedynym sensownym rozwiązaniem jest sformatowanie dysku, opcjonalnie użycie ddrescue do odzyskania danych, jeśli to konieczne.
Uważnie obserwuj napęd. Realokacja sektorów jest bardzo dobrym kanarkiem w kopalni węgla , potencjalnie dając wczesne ostrzeżenie o awarii napędu. Podejmując wczesne działania, możesz zapobiec katastrofalnej i bardzo bolesnej osuwisk. Nie sugeruję, że kilka realokacji sektorów wskazuje, że należy odrzucić dysk. Wszystkie współczesne dyski wymagają pewnej realokacji. Jeśli jednak dysk nie jest bardzo stary (<1 rok) lub otrzymujesz częste nowe alokacje (> 1 / miesiąc), zalecamy jak najszybsze jego zastąpienie.
Nie mam dowodów empirycznych, aby to udowodnić, ale moje doświadczenie sugeruje, że problemy z dyskiem można zmniejszyć, od czasu do czasu czytając cały dysk, albo ddz dysku surowego, albo czytając każdy używany plik find. Prawie wszystkie problemy z dyskami, których doświadczyłem w ciągu ostatnich kilku lat, pojawiły się najpierw w rzadko używanych plikach lub na maszynach, które nie są często używane. Ma to również heurystyczny sens, ponieważ jeśli sektor jest często odczytywany ponownie, napęd ma szansę na przeniesienie go, gdy po raz pierwszy wykryje niewielki problem z tym sektorem, zamiast czekać, aż sektor będzie całkowicie nieczytelny. Dysk nie jest w stanie nic zrobić z sektorem, chyba że host w jakiś sposób uzyska do niego dostęp, czytając go lub pisząc lub przeprowadzając jeden z testów SMART.
Chciałbym eksperymentować z pomysłem codziennej lub cotygodniowej pracy crona, która odczytuje cały dysk. Obecnie używam macierzy RAID „biednego człowieka”, w której mam drugi dysk twardy w komputerze i co wieczór tworzę kopię zapasową dysku głównego. Pod pewnymi względami jest to w rzeczywistości lepsze niż dublowanie RAID, ponieważ jeśli pomyłam i usunę plik przez pomyłkę, mogę natychmiast pobrać wczorajszą wersję z dysku kopii zapasowej. Z drugiej strony uważam, że sprzętowy kontroler RAID wykonuje wiele dobrej pracy w tle, monitorując, zgłaszając i naprawiając problemy z dyskami w miarę ich pojawiania się. Mój obecny skrypt tworzenia kopii zapasowych używa, rsyncaby uniknąć kopiowania danych, które nie uległy zmianie, ale ze względu na potrzebę ponownego przeczytania wszystkich sektorów może lepiej byłoby skopiować wszystko lub mieć osobny skrypt, który co tydzień odczytuje cały dysk.