Hallo.
So, ich nochmal.
Habe versucht, herauszufinden, was die Festplatte davon abhält in den Standby zu gehen bzw. was diese immer wieder aus dem Standby rausholt.
Die Kollegen vom NAS4220 haben hierfür einigen Tools bereitgestellt: local_apps und spindown tracking tool <<<
HIER>>>
Nach ein wenig Adaptionsaufwand, laufen diese Dinge auch auf dem NAS2000.
Voraussetzung hierfür: Laufender SSH Server auf dem NAS, do_it Skript im Einsatz (Anleitungen hierzu im Forum zu finden)
1) drivestate.sh in /mnt/IDE1/public/applications/do_it erstellen (Orginalcode im NAS4220 Wiki zu finden - hier die adaptierte Form des Skripts)
|
Quellcode
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
#!/bin/sh
#
# Watch the spindown state of a hard disk
#
# 04.10.2008 - V2.0 gm
#
DEVICE=/dev/hda
MOUNTPOINTS="/mnt/IDE1 /system"
FINDREASON=1
SLEEPTIME=10
COUNTER=0
echo "Monitoring $DEVICE and mount point(s) $MOUNTPOINTS (Ctrl-C to abort) ..."
#
while (true); do
STATE=`hdparm -C $DEVICE | grep "drive state" | awk '{print $4}'`
if [ "$STATE" != "$OLD_STATE" ]; then
echo -e "\n`date`: $DEVICE: $OLD_STATE -> $STATE"
if [ "$OLD_STATE" = "standby" -a $FINDREASON ]; then
# find reason
echo "Seaching for files accessed within last minute ..."
for i in $MOUNTPOINTS; do
find $i -amin 1 -exec ls -alsdu {} \;
done
echo "done"
fi
COUNTER=0
else
#show clock
HOURS=`expr $COUNTER / 3600`
MINUTES=`expr $COUNTER / 60 - $HOURS \* 60`
SECONDS=`expr $COUNTER % 60`
echo -n -e "\r$HOURS hours, $MINUTES minutes, $SECONDS seconds "
fi
OLD_STATE=$STATE
let COUNTER+=$SLEEPTIME
sleep $SLEEPTIME
done
|
2) Skript ausführbar machen mit chmod 755 drivestate.sh
3) local_apps command tools herunterladen (Link im 4220 Wiki)
4) Local_apps.tar.gz nach /mnt/IDE1/public/applications kopieren
5) Entpacken mit tar -xz -f Local_apps.tar.gz (/mnt/IDE1/public/applications/local_apps wird erstellt)
6) /root/.profile kopieren nach /mnt/IDE1/public/applications/do_it/root.profile
7) root.profile editieren und die $PATH Variable anpassen: z.B. so
|
Quellcode
|
1
|
PATH="$PATH:/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin:/mnt/IDE1/public/applications/local_apps/bin"
|
8) Modifikation am do_it init Skript. Dies hinzufügen:
|
Quellcode
|
1
2
3
4
5
6
7
8
9
10
11
12
|
#
#adding local_apps path to root´s system wide ash profile
#
HD_MNT_POINT=$(cat /usr/sausalito/codb/objects/1/Disk.rootdir 2> /dev/null)
WORK_DIR=$HD_MNT_POINT/public/applications/do_it
if [ -f $WORK_DIR/root.profile ]; then
echo "copy modified .profile template"
cp $WORK_DIR/root.profile /root/.profile
else
echo "$WORK_DIR/root.profile not found ... skipping"
fi
|
Nun das NAS2000 über die Weboberfläche neustarten.
Nach dem Neustart sollte das Kommando find über die Konsole ausführbar sein.
So, nun zu den Ergebnissen:
Ich habe das drivestate.sh Skript ausgeführt und die Festplatte danach über eine zweite Konsole mittels hdparm -y /dev/hda in Standby versetzt. Sie wurde wenige Sekunden später wieder aufgeweckt, ohne das ein Dateizugriff meinerseits stattgefunden hätte.
Hierbei fand das spindown tracking tool zwei Dateien, die frequentiert wurden in den zuvor vergangenen 60 Sekunden (das Skript selbst als es ausgeführt wurde und secrets.tdb)
|
Quellcode
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
icybox> ./drivestate.sh
Monitoring /dev/hda and mount point(s) /mnt/IDE1 /system (Ctrl-C to abort) ...
Sat Nov 29 22:41:28 CET 2008: /dev/hda: -> active/idle
Sat Nov 29 22:41:38 CET 2008: /dev/hda: active/idle -> standby
0 hours, 0 minutes, 20 seconds
Sat Nov 29 22:42:09 CET 2008: /dev/hda: standby -> active/idle
Seaching for files accessed within last minute ...
4 -rwxr-xr-x1 root root 1216 Nov 29 22:41 /mnt/IDE1/public/applications/do_it/drivestate.sh
8 -rw-------1 root root 8192 Nov 29 22:42 /system/hddapp/etc/samba/secrets.tdb
done
0 hours, 26 minutes, 30 seconds
|
So, die secrets.tdb gehört anscheinend zum Samba Server.
Aber warum dieser diese Datei frequentieren musste, weiß ich nicht.
Auch weiß ich nicht, ob und warum eine frequentierte Datei in /system einen Festplattenzugriff nach sich ziehen würde.
Ich denk noch ein wenig drüber nach. Wollte diese Erkenntnisse aber schon mal preisgeben.
EDIT: nach mount ist mir klar warum die Festplatte anläuft:
|
Quellcode
|
1
2
|
/dev/hda1 on /system type ext2 (rw)
/dev/hda2 on /mnt/IDE1 type ext2 (usrquota,grpquota)
|
Hier der Inhalt der secrets.tdb, ausgelesen mit tdbdump:
|
Quellcode
|
1
2
3
4
5
6
7
8
9
|
tdbdump secrets.tdb
{
key(18) = "SECRETS/SID/ICYBOX"
data(68) = "deleted by me"
}
{
key(18) = "SECRETS/SID/(NONE)"
data(68) = "deleted by me"
}
|
Kann damit jemand was anfangen? Ich habe über den Aufbau der Datei nicht viel finden können, leider ...
Gruß
enteiser
Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »enteiser« (30. November 2008, 02:08)