To źródło jest bardziej przekonujące niż ogólna skarga typu „moje dyski nigdy nie przechodzą w stan uśpienia”, ponieważ IceWhale odpowiedziało zarówno planem naprawy produktu, jak i metodą diagnostyczną. Sześć dysków HDD w macierzy RAID5 pozostawało aktywnych nawet po zatrzymaniu aplikacji Docker, więc dochodzenie objęło usługi pamięci masowej i kondycji systemu ZimaOS oraz możliwą aktywność na poziomie jądra.
Następnie ZimaOS 1.3.2 ograniczył zbędne zapytania do dysków i poprawił działanie trybu czuwania. Znacznie później ZimaOS 1.6.0 naprawił kolejny konkretny problem, w którym smartd sporadycznie wybudzał uśpione dyski. Wydania te usuwają znane źródła wybudzeń, ale dysk, który nadal pozostaje aktywny, może być używany przez inną aplikację, system kopii zapasowych, indeksator, zadanie systemu plików, mostek USB lub usługę jądra.
IceWhale zmieniło odpytywanie pamięci masowej w ZimaOS 1.3.2
orca-zhang opisał trzy konkretne optymalizacje zaplanowane dla wersji 1.3.2:
- prostsza logika kontroli kondycji;
- odświeżanie pamięci podręcznej danych dysku tylko po wykryciu zmiany dysku;
- zaprzestanie pobierania takich informacji jak temperatura lub czas pracy dysku z dysku, który już znajduje się w trybie czuwania.
Powód jest istotny: niektóre dyski HDD lub kontrolery nie mogą udzielić odpowiedzi na takie zapytania z pamięci podręcznej, więc żądanie danych o kondycji wybudza fizyczny dysk.
Aktualne informacje o wydaniu wersji 1.3.2 podsumowują te zmiany jako ograniczenie zbędnej aktywności odczytu/zapisu i poprawę działania trybu czuwania dysków.
IceWhale udostępniło polecenie sprawdzające dostęp procesów
Oficjalna odpowiedź źródłowa sugerowała zidentyfikowanie procesów, które aktualnie mają otwarty system plików lub urządzenie:
for pid in $(fuser -m <device_path> 2>/dev/null); do
ps -p $pid -o comm=
done | uniqZastąp <device_path> rzeczywistą ścieżką dysku lub zamontowanej pamięci masowej. To działanie diagnostyczne, a nie destrukcyjne.
IceWhale zasugerowało również tymczasowe zatrzymanie usług pamięci masowej i plików
W ramach diagnostyki źródło sugerowało przetestowanie trybu czuwania po zatrzymaniu następujących usług:
systemctl stop zimaos-local-storage
systemctl stop icewhale-filesIceWhale ostrzegło, że podczas zatrzymania tych usług niektóre funkcje Ustawień i Plików przestaną działać. Używaj tego wyłącznie jako kontrolowanego testu, a następnie uruchom usługi ponownie lub zrestartuj system.
ZimaOS 1.6.0 naprawił kolejne znane źródło wybudzeń
W późniejszym dzienniku zmian wersji 1.6.0 dodano osobną poprawkę: dyski nie mogły przechodzić w normalny stan uśpienia, ponieważ usługa smartd sporadycznie je wybudzała.
Zobacz oficjalną poprawkę trybu czuwania dotyczącą smartd.
Przeniesienie danych aplikacji do NVMe nie gwarantuje bezczynności dysków HDD
Użytkownik źródłowy przeniósł już bazy danych Dockera do NVMe. Dyski HDD mogą jednak nadal być używane przez skanowanie multimediów, kopie zapasowe, miniatury, klientów SMB, kontrole SMART, zadania RAID/parzystości, indeksowanie w Plikach lub proces, który utrzymuje otwartą ścieżkę.
Korzystaj z rzeczywistych dowodów dostępu, zamiast zakładać, że „wszystkie aplikacje są na NVMe” oznacza brak operacji wejścia/wyjścia na macierzy.
RAID5 może generować własną aktywność w tle
Kontrole parzystości, odbudowa, czyszczenie, aktywność metadanych systemu plików i monitorowanie mogą zgodnie z przeznaczeniem uzyskiwać dostęp do każdego członka macierzy. Przed diagnozowaniem trybu czuwania upewnij się, że RAID nie wykonuje długotrwałej operacji konserwacyjnej.
Przed zastosowaniem starych obejść związanych z usługami należy przetestować aktualny system ZimaOS
Aktualna wersja ZimaOS to 1.7.1 i obejmuje lata zmian w zarządzaniu pamięcią masową wprowadzonych po tym zgłoszeniu ze stycznia 2025 roku. Najpierw odtwórz problem w aktualnej wersji, a następnie zidentyfikuj źródło wybudzeń. Nie wyłączaj na stałe usług kondycji ani pamięci masowej tylko po to, aby wymusić zatrzymanie dysków.
Najczęstsze pytania dotyczące trybu czuwania dysków
Czy IceWhale przyznało w źródle, że występował problem z trybem czuwania?
Tak. Pracownicy poinformowali, że problem jest badany, i opisali optymalizacje w wersji 1.3.2.
Czy sprawdzanie temperatury lub kondycji dysku może wybudzić niektóre dyski?
Tak. IceWhale wyraźnie stwierdziło, że niektóre dyski bez zapisanych w pamięci podręcznej informacji mogą zostać wybudzone podczas odpytywania.
Czy później zidentyfikowano smartd jako kolejne źródło wybudzeń?
Tak. ZimaOS 1.6.0 wyraźnie naprawił sporadyczne wybudzenia powodowane przez smartd, które uniemożliwiały normalne przechodzenie dysków w stan uśpienia.
