Jak mogę kontrolować czas przestoju HDD?

W komputerze mam 2 dyski twarde. Ubuntu bardzo szybko wyłącza dodatkowy dysk twardy po około 15 minutach, co jest dla mnie skrótem. Tym razem muszę kontrolować. Jak mogę to zrobić?

Próbowałem zarządzania energią GNOME, ale nie uznałem go za przydatny.

Spójrz na hdparm.

Z instrukcji ( man hdparmw wierszu poleceń):

-S Ustaw limit czasu oczekiwania (spindown) dla napędu. Ta wartość jest używana przez przemiennik do określenia czasu oczekiwania (bez aktywności dysku) przed wyłączeniem silnika wrzeciona w celu oszczędzania energii. W takich okolicznościach dysk może zająć nawet 30 sekund na odpowiedź na kolejny dostęp do dysku, chociaż większość dysków jest znacznie szybsza.

Kodowanie wartości limitu czasu jest dość osobliwe. Wartość zero oznacza „limity czasu są wyłączone”: urządzenie nie przejdzie automatycznie w tryb gotowości. Wartości od 1 do 240 określają wielokrotności 5 sekund, dając limity czasu od 5 sekund do 20 minut. Wartości od 241 do 251 określają od 1 do 11 jednostek 30 minut, dając limity czasu od 30 minut do 5,5 godziny. Wartość 252 oznacza limit 21 minut. Wartość 253 ustawia limit czasu zdefiniowany przez dostawcę na 8–12 godzin, a wartość 254 jest zarezerwowana. 255 jest interpretowane jako 21 minut plus 15 sekund. Pamiętaj, że niektóre starsze dyski mogą mieć bardzo różne interpretacje tych wartości.

sudo hdparm -I /dev/sdb | grep levelPokaże więc bieżącą wartość spindown, na przykład:

Advanced power management level: 254

Z instrukcji: 254 jest zarezerwowane, więc spodziewam się, że będzie to domyślna wersja Ubuntu (czy ktoś może to potwierdzić / rozwinąć?)

Przykład:

sudo hdparm -S 25 /dev/sdb = spindown po 25 * 5 sekundach.

sudo hdparm -S 245 /dev/sdb = spindown po (245–240) * 30 minut.

Narzędzie dyskowe -> wybierz dysk HDD -> kliknij ikonę „Więcej działań ...” w prawym górnym rogu -> Ustawienia napędu ...

Mój wygląda następująco:

Jeśli chcesz, aby ustawienie hdparm było trwałe między restartami, zamiast dodawać je do pliku crontab, możesz użyć /etc/hdparm.conf. Mam następujące uwagi, zwróć uwagę na użycie dużej litery S, a nie małych liter:

command_line {
    hdparm -S 25 /dev/disk/by-uuid/f6c52265-d89f-43a4-b03b-302c3dadb215 
}

Dodaj ten wiersz, zastępując UUID swoim, lub możesz określić urządzenie za pomocą /dev/sdXformatu. Możesz znaleźć identyfikator UUID dysku za pomocą polecenia sudo blkid.

1. Znajdź identyfikator UUID dysku .

   sudo lsblk --output NAME,FSTYPE,LABEL,UUID,MODE
   

2. Edytować /etc/hdparm.conf

   sudo -H gedit /etc/hdparm.conf  # Be careful from now on
   

3. Poszukaj spindown-timesekcji ustawień dysku.

   /dev/disk/by-label/4TB {
       spindown_time = 1200
   }
   

4. Wolę odnosić się do dysku przez UUID, który pozostaje taki sam w różnych instalacjach (chyba że zmienisz go w samym HW).

   /dev/disk/by-uuid/91e32677-0656-45b8-bcf5-14acce39d9c2 {
       spindown_time = 1200
   }
   

5. Jeśli skrypt inicjujący powoduje problemy z uruchamianiem, możesz przekazać nohdparm wiersz poleceń jądra, a skrypt nie zostanie uruchomiony.

Po spędzeniu wielu godzin odkryłem, że mój napęd WDC nie obsługuje polecenia hdparm -S, bez względu na wartość atrybutu idle3 (google: idle3ctl). I to jest powszechny problem z dyskami WD. Ale miło mi poinformować, że hd-idle ( http://hd-idle.sourceforge.net/ ) działa bezbłędnie. Jeśli jest instalowany z pakietu zbudowanego przez dpkg (patrz Uwagi dotyczące instalacji), tworzy demona zarówno na Ubuntu, jak i na Debianie (konfiguracja znajduje się w / etc / default / hd-idle). Działa również dobrze po wznowieniu hibernacji.

mc default # ps aux | grep hd-idle | grep -v grep | cut -c 66-; dla f w [reklamie]; wykonaj hdparm -C / dev / sd $ f | grep -v "^ $"; gotowy
/ usr / sbin / hd-idle -i 1800 -a sdc -i 600 -a sdd -i 60 -l /var/log/hd-idle.log
/ dev / sda:
 stan napędu to: aktywny / bezczynny
/ dev / sdb:
 stan napędu to: tryb gotowości
/ dev / sdc:
 stan napędu to: tryb gotowości
/ dev / sdd:
 stan napędu to: tryb gotowości

Odkryłem, że zachowanie Samsung HD204UI w trybie spindown zależy od poziomu APM ( hdparm -B). Jeśli poziom APM wynosi 127, limit czasu spindown wynosi 10 s. Jeśli poziom APM wynosi 150, limit czasu spindown jest definiowany przez -Sopcję.

Dodaję coś takiego:

@reboot sudo hdparm -S244 /dev/disk/by-uuid/71492809-e463-41fa-99e2-c09e9ca90c8e  > /dev/null 2> /dev/null

do crontab roota. Myślę, że używanie UUID jest lepsze, ponieważ sda/ sdbetc wydaje się zmieniać przy każdym ponownym uruchomieniu

W Ubuntu 14.04

Dyski> zaznacz dysk> kliknij koło zębate w prawym górnym rogu> Ustawienia dysku> teraz masz ustawienia Standby, APM, AAM i Write Cache w łatwym w obsłudze GUI!

W Debianie, z dyskami WD, stwierdzam, że ustawienie dowolnego poziomu za pomocą hdparm -S powoduje, że dysk zwraca poziom 254 na kolejnym hdparm -I . Więc naprawdę nie jestem pewien, czy się obracają, czy nie. Myślę, że wciąż się rozwijają.

Te dyski znajdują się w macierzy serwerów i naprawdę nie chcę, żeby się kiedykolwiek zawirowały. W przeszłości miałem takie problemy, ustawiając zadanie crona, aby aktualizowało plik co kilka minut.

Nie miałem szczęścia z hdparmem na zewnętrznym dysku twardym zamontowanym w obudowie USB, której używam do obsługi mediów za pomocą minidlny.

Natrafiłem tutaj na pomysł: https://serverfault.com/questions/562738/keeping-usb-backup-drive-from-sleeping-while-mounted

Najlepsze wyniki uzyskuje się za pomocą UUID dysku, który można znaleźć za pomocą:

sudo blkid

Poniższa metoda wymaga dostępu do konta root, ale także hdparm. Używa crontab do odczytu losowego bloku z dysku co 5 minut i ignoruje wszystkie wiadomości. Aby upewnić się, że masz odpowiedni identyfikator UUID, przetestuj go w wierszu polecenia w ten sposób (upewnij się, że używasz żądanego UUID, a nie tego):

sudo dd if=/dev/disk/by-uuid/f01df4b5-6865-476a-8d3b-597cbd886d41 of=/dev/null count=1 skip=$RANDOM

Powinieneś zobaczyć takie dane wyjściowe:

1+0 records in
1+0 records out
512 bytes copied, 0.000738308 s, 693 kB/s`

Aby ukryć ten komunikat, który może gdzieś zostać zapisany, potencjalnie system plików / (w moim przypadku na dysku SSD), poniżej znajduje się to, czego używam w głównym pliku crontab. Dostajesz się tam z

sudo crontab -e

Następnie pod komentarzami:

*/5 * * * * bash -c 'dd if=/dev/disk/by-uuid/f01df4b5-6865-476a-8d3b-597cbd886d41 of=/dev/null count=1 skip=$RANDOM' >/dev/null 2>&1

Mam nadzieję, że to pomoże komuś innemu z podobnymi problemami. Niestety, nadal jest to zapisywane w dzienniku systemowym, ale istnieją potencjalne sposoby na powstrzymanie tego; zobacz ten post ServerFault .

[edytuj] 2017-01-07 09:02:

Byłem w stanie ukryć te wiadomości, edytując /etc/rsyslog.d/50-default.conf, aby zmienić ten wiersz:

*.*;auth,authpriv.none -/var/log/syslog

do tego:

*.*;cron,auth,authpriv.none -/var/log/syslog

Niestety, tłumi to wszystkie wiadomości cron; Nie mogłem przekonać crona do przekierowania wylogowania z głównego systemu plików (który w moim przypadku jest na starzejącym się dysku SSD, więc chcę ograniczyć zapisy), ale ponieważ jest to tylko serwer domowy, prawdopodobnie nie brakuje mi zbyt wiele. Zdecydowanie nie poleciłbym tej strategii dla maszyny produkcyjnej.