Mam dysk twardy Western Digital Elements Desktop podłączony przez USB. Zasadniczo jest to świetny pakiet dla dysku WD30EZRX. Używam go do przechowywania kopii zapasowych systemu (teraz już stare), więc nie ma w tym nic krytycznego. Prawdopodobnie mógłbym go teraz wytrzeć i wyrzucić i niczego nie umknie.
Kilka miesięcy temu skutecznie wymieniłem wyżej wymieniony dysk na inny, ale zachowałem ten stary (częściowo na wypadek, gdy muszę odwołać się do starszej wersji jakiegoś pliku, częściowo dlatego, że zamierzałem go przekonwertować na dysk kopii zapasowych poza witryną). Został podłączony i zasilony, ale nieużywany; system plików nie został zamontowany, więc jedyną czynnością, którą powinien zobaczyć, jest skanowanie tablicy partycji podczas rozruchu i być może ZFS szukał kilka razy, aby sprawdzić, czy jest na nim jakaś partycja, która jest częścią puli.
Mniej więcej miesiąc temu skonfigurowałem smartd do monitorowania stanu różnych dysków podłączonych do mojego systemu. Natychmiast wykrzyczał krwawe morderstwo na temat tego dysku, zgłaszając liczbę oczekujących (nieczytelnych) sektorów wynoszącą 5. Wiedząc, że same sektory oczekujące na zarządzanie są możliwe do zarządzania, utrzymałem dysk podłączony, ale nieużywany.
Dziś po południu raport e-mail od smartd nagle wskazuje, że istnieje 6 oczekujących sektorów, a także 1 sektor, którego nie można naprawić w trybie offline (jest to nowy).
Oto dziwna część: ostatni restart, a więc kiedy dysk powinien był zobaczyć jakąkolwiek aktywność ostatnio, miał miejsce prawie cztery dni temu.
Dysk logicznie przechowuje jedną partycję obejmującą cały dysk, na której znajduje się kontener LUKS, który nie został uruchomiony w tym okresie, odkąd skonfigurowałem smartd do monitorowania stanu dysku. Nigdy nie był częścią żadnej macierzy RAID lub podobnej na dowolnym poziomie (dysk, partycja, kontener LUKS, zamknięty system plików).
Sprawdzanie za smartctl --all
pomocą napędu informuje, że nie został zarejestrowany autotest. Potwierdza to również liczbę oczekujących sektorów wynoszącą 6, a także liczbę poprawialnych połączeń offline wynoszącą 1.
Co mogło spowodować wzrost liczby sektorów oczekujących i sektorów niemożliwych do korekty w trybie offline, gdy dysk nie powinien nawet widzieć żadnej aktywności?
Uwaga: nie pytam, czy powinienem nadal używać tego napędu. W tym momencie staje się to oczywiście niewiarygodne i zostanie wycofane; Zbyt wiele razy cierpiałem na utratę danych z powodu awarii dysku twardego, aby zaryzykować moje dane.