Uśpij dysk twardy i wybudzaj się tylko w razie potrzeby

10

Chcę podłączyć inny dysk twardy do mojego komputera, który chcę spać 99% czasu. Użyję go tylko do kilku rzeczy, ale muszę go zawsze montować.

Aby to osiągnąć, chciałbym wiedzieć:

Jak zalogować, które procesy uzyskują dostęp do urządzenia? Potrzebuję rejestrowania, aby móc stwierdzić, co powoduje wznowienie działania dysku twardego, jeśli tak się stanie, więc mogę na nim działać.
Czy muszę wprowadzić jakieś specjalne ustawienia jądra, aby urządzenie mogło spać dłużej?
Jak ustawić przedziały uśpienia dysku twardego?

linux hard-drive

— Usunięte
źródło

13

Interwał snu nazywa się „APM” (automatyczne zarządzanie energią) i czas spindown_time. Jest to kontrolowane w hdparmnastępujący sposób:

hdparm -B 50 -S 36 /dev/disk/by-label/BACKUP-HDD

Sprawi, że twój dysk twardy wyłączy się po ~ 3min braku aktywności.

— kolypto
źródło

4

W systemie Linux możesz korzystać z nowego fatracenarzędzia, które rejestruje każdy dostęp do pliku i informuje, który proces jest odpowiedzialny:

https://launchpad.net/fatrace

Więcej informacji tutaj:

http://www.piware.de/2012/02/fatrace-report-system-wide-file-access-events/

Wykorzystuje API linuksowe fanotify ( więcej szczegółów ) dostępne od jądra Linuksa 2.6.37.

fatrace nie jest spakowany we wszystkich dystrybucjach od lipca 2014 r. (niedawno wszedł w testy Debiana, więc powinien zostać dostarczony w wersji „jessie”), ale jest łatwy do zainstalowania ze źródła.

— JosephH
źródło

1

Nie wiem, co rozumiesz przez „większość” dystrybucji. Jak zwykle Debian to ostatnia dystrybucja, która coś zdobyła. Mam go na Fedorze od dłuższego czasu ...

— Michael Hampton

3

http://en.wikipedia.org/wiki/Fuser_%28Unix%29 - fuser to komenda UNIX służąca do pokazania, które procesy używają określonego pliku, systemu plików lub gniazda.

http://sourceforge.net/projects/hdparm/ - pobierz / ustaw parametry napędu ATA / SATA w systemie Linux (poszukaj opcji -S)

http://sg.danny.cz/sg/sg3_utils.html - Pakiet sg3_utils zawiera narzędzia, które wysyłają polecenia SCSI do urządzeń. Jak również urządzenia w transporcie tradycyjnie związane z SCSI (poszukaj sg_start)

— Maciek Sawicki
źródło

Dziękuję za twoją pouczającą odpowiedź! Wygląda na to, że fuser mówi mi tylko, które procesy używają pliku, systemu plików i gniazda w momencie wydania polecenia. Chociaż jest to bardzo przydatne, jeśli proces wykonuje coś szybko, na przykład wyświetla zawartość katalogu głównego urządzenia, mogę go przegapić, nawet jeśli mam nagrzewnicę uruchomioną w pętli. Gdyby było coś, co czekałoby i zapisywało całą aktywność, dopóki nie powiem, żeby przestało, byłoby to jeszcze bardziej pomocne w tej sytuacji. Wiesz coś o jakimś?

— Usunięte

Myślę, że hdparam jest tym, czego użyję do ustawienia czasu oczekiwania przed snem? A sg3_utils to tylko potężne narzędzie, ale nie użyję go w tym przypadku? (Myślę, że nie będę musiał ręcznie określać, kiedy dysk twardy powinien spać po skonfigurowaniu go za pomocą hdparam?)

— Usunięte

3

btracelub blktrace(wrapper of btrace) śledzić blok we / wy jądra i może ci w tym pomóc.

— zaraz
źródło

2

lsof +D /path/to/mount powinien pokazywać każdy proces, który ma otwarty plik we wskazanej ścieżce.

— Miś
źródło

0

Mam podobny problem. Mam SSD, /dev/sdbz systemem operacyjnym (Linux Mint 18.1 oparty na Ubuntu Xenial) i HDD /dev/sda, z danymi, których używam od czasu do czasu. Oba dyski są szyfrowane. Partycje dysku twardego nie są zamontowane. W każdym razie po kilku minutach HDD budzi się, potem śpi, a następnie budzi się ponownie. Bałagan.

Oto duplikat pytania z pomocną odpowiedzią , która sugeruje auditdznalezienie procesu złego zachowania.

apt-get install auditd
auditctl -w /dev/sda -p rwa

Następnie zmuszam dysk twardy do snu hdparm -Y /dev/sda. Następnie poczekaj, aż usłyszę ponowne uruchomienie dysku twardego. Potem biegnij ausearch -f /dev/sda. W moim przypadku pokazuje wpisy takie jak poniżej.

time->Sat Feb 25 12:38:17 2017
type=PROCTITLE msg=audit(1488022697.651:1744): proctitle=2F7573722F6C69622F756469736B73322F756469736B7364002D2D6E6F2D6465627567
type=PATH msg=audit(1488022697.651:1744): item=0 name="/dev/sda" inode=376 dev=00:06 mode=060660 ouid=0 ogid=6 rdev=08:00 nametype=NORMAL
type=CWD msg=audit(1488022697.651:1744):  cwd="/"
type=SYSCALL msg=audit(1488022697.651:1744): arch=c000003e syscall=2 success=yes exit=12 a0=f3fb90 a1=800 a2=7f4745221f64 a3=30 items=1 ppid=1 pid=18520 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="pool" exe="/usr/lib/udisks2/udisksd" key=(null)

Odpowiednia część to exe = "/ usr / lib / udisks2 / udisksd" . Chociaż ja także miałem smartmontoolsktórego smartdbył również sprawcą. Odinstalowałem smartmontoolsi zatrzymałem udisk2usługę za pomocą service udisks2 stop. Następnie dysk twardy śpi zgodnie z oczekiwaniami.

Pamiętaj, że udisks2uruchomi się automatycznie, gdy na przykład otworzę aplikację Dyski , więc muszę ją ponownie zatrzymać. Inną wadą jest to, że parametry SMART nie są monitorowane dla obu dysków, co nie jest dobre, ale jako obejście to pasuje.

Jedną z niejasnych kwestii jest to, że ten raport o błędach mówi, udisks2że nie wykonuje odpytywania dysków, co jest teraz wykonywane przez jądro. Ale dowody wydają się wskazywać na coś przeciwnego.

— saaj
źródło