Wer weckt Dornr^W meine Festplatte auf?

[Andreas Leitgeb]

Habe einen neuen Rechner nun so eingerichtet, dass das System
auf einer kleinen (2½") Platte ist (vl später mal eine SSD),
und das /opt filesystem auf einer großen (3½") Platte ist.

Die Daten auf /opt, dachte ich, würden eh nur von mir selber
angeschaut, und daher könnte ich die große Platte mit hdparm
in standby versetzen, bis ich sie wieder brauch. Oft laeuft
sie aber bereits relativ kurz nach dem Schlafenlegen wieder
an. Ein gleich nach einem unerwartetem Hochdrehen getipptes
sudo lsof | grep /opt
fand aber nichts - war wohl immernoch zu langsam.

Mich würd nun interessieren, welche Prozesse da noch
auf /opt herumkramen, damit ich für jeden solchen Prozess
eine spezifische Lösung finden kann.

Ein solcher prozess ist natürlich mlocate, aber den hänge
ich auf weekly um. Einmal pro Woche darf er dann die hd
aufwecken.

Würde ich /opt einfach un-mounten, dann würde es auch
nicht mehr von mlocate erfasst werden.

[Johann Klammer]

Ich glaub cron schaut jede sekunde in die crontab.
Updatedb laeuft jeden tag un graebt das Ganze
Dateisystem um.
Im /var/log landen die ganzen logfiles.
Falls das Swapfile auch auf der festplatte ist versuche:
echo 0>/proc/sys/vm/swappiness

Ich glaube es gibt da die laptop mode tools,
die ein bisschen am system herumschrauben,
damit die festplatte laenger im standby bleiben kann.
Vielleicht hilfts ja was.

JK

[Andreas Leitgeb]

Johann Klammer <klam...@NOSPAM.aon.at> wrote:
> Ich glaub cron schaut jede sekunde in die crontab.
> Updatedb laeuft jeden tag un graebt das Ganze
> Dateisystem um.

updatedb ist das, was ich mit mlocate meinte.
(unter ubuntu heisst der anacron-job mlocate).

> Im /var/log landen die ganzen logfiles.
> Falls das Swapfile auch auf der festplatte ist versuche:
> echo 0>/proc/sys/vm/swappiness

Die zwei Faktoren kann ich ausschließen.

> Ich glaube es gibt da die laptop mode tools,
> die ein bisschen am system herumschrauben,
> damit die festplatte laenger im standby bleiben kann.

Bin zwar noch nicht über diese settings gestolpert,
kann mir aber vorstellen, dass laptops meistens nur
eine FP drin haben, und dass die situation: "nur die
zweite platte schonen" nicht ganz so mainstream ist.

Mittlerweile hab ich ein Beobachtungstool geschrieben,
das mir sagt, wann die zweite FP jeweils aufgewacht ist,
und das scheint nun darauf hinzudeuten, dass es doch nur
der schon genannte updatedb/mlocate ist. Dass mir die
platte anfangs "gleich wieder" aufgewacht ist, lag wohl
daran, dass ich vergessen hatte, zwischen dem letzten
write und dem schlafenlegen noch einen sync zu machen :-}

[Johann Klammer]

es gibt da noch:
/proc/sys/vm/laptop_mode
/proc/sys/vm/dirty_writeback_centisecs

letzteres ist default auf 5 sekunden.
Kann man ruhig hoeher setzen, wenn die kiste
nicht dauernd abstuertzt und datenverlust
befuerchtet wird.

[Andreas Leitgeb]

Danke für den Hinweis - ich habe ihn inzwischen anderswo
nutzen können :-)

Auf der eigentlichen Maschine habe ich jetzt mal den
anacron-job für locate auf weekly umgehaengt, und ein
script protokolliert mir weiterhin die Zeiten, wann die
FP aufwacht. (bis heute täglich so um 8Uhr in der Früh)
Künftig sollte das dann nur noch im Wochenraster
passieren... (naja, sofern ich nicht eh selber öfter
auf die FP zugreife)

[Stefan Enzinger]

On 01/11/2012 09:51 AM, Andreas Leitgeb wrote:

> Mittlerweile hab ich ein Beobachtungstool geschrieben,
> das mir sagt, wann die zweite FP jeweils aufgewacht ist,

Wie testest du, ob die Platte aufgeweckt wurde?
hdparm -C
Weckt mir die Platte jedesmal auf.

Könnte man mit inotify Zugriffe auf den mountpoint und alles darunter
loggen?

lg

[Andreas Leitgeb]

Stefan Enzinger <min...@aon.at> wrote:
> On 01/11/2012 09:51 AM, Andreas Leitgeb wrote:
>> Mittlerweile hab ich ein Beobachtungstool geschrieben,
>> das mir sagt, wann die zweite FP jeweils aufgewacht ist,
> Wie testest du, ob die Platte aufgeweckt wurde?
> hdparm -C
> Weckt mir die Platte jedesmal auf.

Genau das verwende ich, und bei mir weckt es
die Platte *nicht* auf.

[Andreas Leitgeb]

Nachsatz: Ubuntu 11.10
hdparm - get/set hard disk parameters - version v9.37, by Mark Lord.

strace:
open("/dev/sdb", O_RDONLY|O_NONBLOCK) = 3
ioctl(3, SG_IO, {'S', SG_DXFER_NONE, cmd[16]=[85, 06, 20, 00,
00, 00, 00, 00, 00, 00, 00, 00, 00, 40, e5, 00], mx_sb_len=32,
iovec_count=0, dxfer_len=0, timeout=15000, flags=0, status=02,
masked_status=01, sb[22]=[72, 00, 00, 00, 00, 00, 00, 0e, 09, 0c,
00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 40, 50], host_status=0,
driver_status=0x8, resid=0, duration=0, info=0x1}) = 0

PS: kann es sein, dass du dieselbe FP testest, auf der auch
das hdparm-utility selber drauf ist? ;)