Montag, 20. November 2017, 01:21 UTC+1

Sie sind nicht angemeldet.

  • Anmelden
  • Registrieren

Lieber Besucher, herzlich willkommen bei: NAS Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Freitag, 4. April 2008, 19:35

Probleme mit HDD Spin-Down nach Stromausfall

Hallo Forum,

seit ein paar Tagen habe ich Probleme mit der Spin-Down Funktion in meiner NAS-2000. Als ich das Gerät vor einigen Monaten eingerichtet habe, hatte ich die Spin-Down Funktion mit einer Verzögerung von 15 Minuten über die Weboberfläche aktiviert. Das hat seitdem auch prima funktioniert.

Vergangenes Wochenende gab es hier einen Stromausfall, und die NAS-2000 wurde einfach abgeschaltet ohne sauber herunter zu fahren. Nach einem Neustart waren keine Fehler erkennbar, jedoch funktioniert die Spin-Down Funktion seitdem nicht mehr und die Festplatte ist ständig an.

Ich habe in der Zwischenzeit die folgende Dinge ausprobiert, allerdings ohne Erfolg:

- Netzwerkkabel abgetrennt um sicher zu stellen, dass nicht irgendein PC im Netzwerk das Gerät durch Datentransfer in Betrieb hält und am Schlaf hindert.

- Ich habe die Spin-Down Zeit manuell mit 'hdparm -k1 -K1 -S120 /dev/hda' über ein SSH-Login gesetzt. Das Kommando hat funktioniert und die folgede Ausgabe erzeugt.

/dev/hda:
setting keep_settings to 1 (on)
setting drive keep features to 1 (on)
setting standby to 120 (10 minutes)
keepsettings = 1 (on)

Die Platte wird aber nicht abgeschaltet.

- Ich habe die Zeit über die Weboberfläche geändert um zu testen, ob die neue Zeit nach einer Änderung geschrieben wird.

Hat jemand eine Idee?

Im Voraus bereits vielen Dank für die Hilfe,

CB



Hardware:
==========================
NAS-2000, Hardware Rev. B w/ Tinky 2.3.2-mu-02.2
HDD: SAMSUNG SP2514N, Firmware: VF100-50

Laufende Prozesse:
====================================
PID USER COMMAND
1 root init
2 root [ksoftirqd/0]
3 root [desched/0]
4 root [events/0]
5 root [khelper]
10 root [kthread]
20 root [kblockd/0]
33 root [khubd]
72 root [pdflush]
73 root [pdflush]
75 root [aio/0]
74 root [kswapd0]
730 root init
731 root /bin/sh /etc/rc
759 root [tar]
840 root [kjournald]
864 root [eth0]
868 root /usr/sausalito/sbin/cced
883 root [syslogd]
887 root /usr/sbin/inetd
937 root [S90crond.sh]
947 root [crond]
965 root /sbin/syslogd
1048 nobody [proftpd]
1062 nobody proftpd: (accepting connections)
1103 root [smbd]
1105 root [smbd]
1106 root [nmbd]
1128 root /usr/hddapp/sbin/smbd -D
1130 root /usr/hddapp/sbin/smbd -D
1131 root /usr/hddapp/sbin/nmbd -D
1137 root [S90crond.sh]
1142 root [subConflict]
1152 root [subConflict]
1161 root /usr/sbin/crond
1175 root /usr/sausalito/sbin/storudp
1177 root /usr/sausalito/handlers/base/power/powermgmt
1188 root /sbin/syslogd
1194 root /usr/sbin/crond
1200 root /usr/sbin/thttpd -C /etc/thttpd.conf
1202 root /sbin/upnpdevice
1205 root sh /system/overlay/bin/tinky
1267 root [thttpd]
1270 root [thttpd]
1274 root [thttpd]
1278 root [thttpd]
1279 root [thttpd]
1281 root [thttpd]
1285 root [thttpd]
1290 root [thttpd]
1288 root [thttpd]
1293 root [thttpd]
1301 root [thttpd]
1307 root [thttpd]
1309 root dropbear -i
1310 root -ash
1313 root ps -ef

HWguru

NAS2000-Team

Beiträge: 1 001

Wohnort: Wien

2

Dienstag, 15. April 2008, 10:56

RE: Probleme mit HDD Spin-Down nach Stromausfall

Hallo Codebotcher,
hast du versucht das Filesystem zu überprüfen? Ich nehme an du nutzt ext2/3 Filesystem.

Ich würde annehmen, dass da durch den Stromausfall was Schaden genommen hat.

1. Diskcheck über die Web Oberfläche
2. mit e2fsck - über die Konsole oder die Box über USB an einen Linux Rechner stöpseln

lG HWguru
Leute ohne Laster haben oft wenige Tugenden...
NAS2000 2.3.2.IB.2.RS.1+Lüfterabschaltung+SSH+do_it+zusätzliche commandline tools+changed root password
1. suchen - lesen - Google - lesen - 1. Fragen gehören ins Forum, dann profitieren alle davon!

3

Samstag, 29. November 2008, 00:09

Hallo.

Ich hatte dasselbe Problem.
Die Festplatte im NAS ging einfach nicht "schlafen".

Per SSH funktioniert e2fsck nicht, da die Platte gemounted und busy ist.

Kurzerhand habe ich mir die GRML live CD runtergeladen und auf CD gebrannt (andere Linux Live Versionen funktionieren sicherlich auch).
NAS2000 per USB ans Notebook angeschlossen, GRML booten.

e2fsck -p -f /dev/sde1
e2fsck -p -f /dev/sde2

Nach ca 2 Stunden waren Check und evtl Reparaturen beendet.

NAS2000 ordnungsgemäß ausgeschaltet, per LAN verbunden, hochgefahren. Fertig.
Hiernach funktionierte das Spin Down wieder.


Danke für den Tipp

Gruß
enteiser

4

Samstag, 29. November 2008, 21:55

Hallo.

Sieht so aus, als ob ich mich geirrt habe.
Der Check ist sicherlich eine gute Sache, hat die Ursache anscheinend aber nicht beseitigt.

Habe Twonkymedia mal durchforstet. Rescan ist abgeschaltet
Die Error notifications ebenfalls.


Habt ihr evtl noch eine Idee woran es liegen kann, das die Festplatte nicht in den Standby geschickt wird?

Gruß
enteiser

5

Samstag, 29. November 2008, 23:19

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)


HWguru

NAS2000-Team

Beiträge: 1 001

Wohnort: Wien

6

Mittwoch, 3. Dezember 2008, 23:19

Hallo enteiser,
ich habe bei jetzt auch mal die Plattenzugriffe belauscht.
Bei mir wird auch auf die secrets.tdb Datei zugegriffen.

Zugriffe auf /system landen natürlich auf der Festplatte, weil das die Systempartition ist, wo auch die Benutzereinstellungen gespeichert werden.

Zitat

Nas> mount
usbfs on /proc/bus/usb type usbfs (rw)
/dev/hda1 on /system type ext2 (rw)
/dev/hda2 on /mnt/IDE1 type ext3 (usrquota,grpquota)


Von gmeyer gibt es hier im nas.portal für das NAS4220 einen Workaround, der auch für unser NAS1000 bzw. NAS2000 funktioniert. Vielen Dank gmeyer!

Folgende Zeilen in das init.us Skript einfügen (welches nach sausalito läuft):

Quellcode

1
2
3
4
5
6
7
8
# move /system/hddapps/etc/samba/secrets.tdb to /etc/samba (RAM-Disk) and
# restart samba to help spindown
echo "move secrets.tdb to /etc/samba and restart samba ..."
/system/hddapp/etc/rc.d/S80samba.sh stop
mkdir /etc/samba
cp /system/hddapp/etc/samba/secrets.tdb /etc/samba
mount -o bind /etc/samba/secrets.tdb /system/hddapp/etc/samba/secrets.tdb
/system/hddapp/etc/rc.d/S80samba.sh start


oder gleich den ganzen Tree

Quellcode

1
2
3
4
5
6
7
8
# move /system/hddapps/etc/samba/secrets.tdb to /etc/samba (RAM-Disk) and
# restart samba to help spindown
echo "move /system/hddapp/etc/samba to /etc/samba and restart samba ..."
/system/hddapp/etc/rc.d/S80samba.sh stop
mkdir /etc/samba
cp -r /system/hddapp/etc/samba /etc
mount -o bind /etc/samba /system/hddapp/etc/samba
/system/hddapp/etc/rc.d/S80samba.sh start


lG HWguru

P.S. läuft gerade bei mir im Test...
Leute ohne Laster haben oft wenige Tugenden...
NAS2000 2.3.2.IB.2.RS.1+Lüfterabschaltung+SSH+do_it+zusätzliche commandline tools+changed root password
1. suchen - lesen - Google - lesen - 1. Fragen gehören ins Forum, dann profitieren alle davon!

7

Samstag, 6. Dezember 2008, 10:56

Hallo HWguru

Super. Danke für den Hinweis im 4220 NAS Portal.

Installation des userscripts ging reibungslos.
Und nachdem ich die secrets.tdb umgemounted hatte, blieb die Festplatte schon mal mehrere Stunden im Standby.

Ich versuch nochmal den gesamten tree auszulagern, da ab und zu die smbpasswd noch im spindown tool protokolliert wird.

Gruß
enteiser

HWguru

NAS2000-Team

Beiträge: 1 001

Wohnort: Wien

8

Samstag, 6. Dezember 2008, 14:30

So, jetzt habe ich das ganze, so glaube ich, gründlich getestet.

Es bestand ja die Befürchtung dass eventuell beim Umleiten des gesamten Verzeichnisses dann beim Booten was verloren geht.
Das File smbpasswd wird zwar beim Booten nicht neu gebaut, aber zB beim Erstellen eines neuen Users wird in beide Dateien geschrieben. In die auf der Ramdisk und der Festplatte.

Also ist nach einem Reboot wieder alles ok!

So wie ich das "ergoogelt" und verstanden habe, liegt das am "mount -o bind ..."

Deshalb wird auch die Platte geweckt, wenn in eine der Dateien geschrieben wird.
Bei Lesezugriffen gewinnt scheinbar die Ramdisk und somit schlummert die Platte weiter. :happy:

lG HWguru
Leute ohne Laster haben oft wenige Tugenden...
NAS2000 2.3.2.IB.2.RS.1+Lüfterabschaltung+SSH+do_it+zusätzliche commandline tools+changed root password
1. suchen - lesen - Google - lesen - 1. Fragen gehören ins Forum, dann profitieren alle davon!

9

Donnerstag, 8. Januar 2009, 16:03

muß ich die init.us selber erstellen oder ist die schon von vornherein irgendwo vorhanden, wo ich sie bearbeiten kann?
wenn ich sie selber erstellen muß: in welchem verzeichnis? unter new_software bzw. da wo auch das do_it script liegt?

im do_it script selber würde ich ja folgende zeilen zur ausführung von init.us hinzufügen:
if [ ! -e /usr/sausalito/constructor/99_execute_userscript ]; then
ln -s $WORK_DIR/init.us /usr/sausalito/constructor/99_execute_userscript


wo ist $WORK_DIR definiert? oder kann ich hier einfach den kompletten pfad angeben, wo mein init.us script liegt? (also z.b. /mnt/IDE1/public/applications/do_it/init.us)



EDIT:
ah ich sehe gerade wenn man schon das do_it script benutzt ist in der init-datei ja schon das $WORK_DIR definiert und zwar so wie ich bereits vermutet hatte. wenn ich die init.us also wie oben belasse und sie im do_it verzeichnis erstelle sollte das klappen....
wär trotzdem nett, wenn jemand mir als linux-lehrling das bestätigen könnte bzw. berichtigen im fehlerfall ;)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »jimpoison« (8. Januar 2009, 16:21)


HWguru

NAS2000-Team

Beiträge: 1 001

Wohnort: Wien

10

Donnerstag, 8. Januar 2009, 16:34

muß ich die init.us selber erstellen oder ist die schon von vornherein irgendwo vorhanden, wo ich sie bearbeiten kann?
wenn ich sie selber erstellen muß: in welchem verzeichnis? unter new_software bzw. da wo auch das do_it script liegt?
nein, die Datei gibt es noch nicht.Im di_it Verzeichnis parallel zu init ist sicher ein guter Platz.
Erstelle sie selber. Der Name ist eigentlich egal. Ich hatte nur init.us übernommen, damit das mit dem Sprachgebrauch bei dem NAS4220 zusammenpasst (skara's Userskript Paket)

Genau, WORK_DIR sollte im init bereits definiert sein.
Das ganze muss dann eben auf init.us zeigen. Sinn dieser ganzen Übung ist, dass das script möglichst spät ausgeführt wird, möglichst wenn die gane Firmware gebootet hat.

lG HWguru
Leute ohne Laster haben oft wenige Tugenden...
NAS2000 2.3.2.IB.2.RS.1+Lüfterabschaltung+SSH+do_it+zusätzliche commandline tools+changed root password
1. suchen - lesen - Google - lesen - 1. Fragen gehören ins Forum, dann profitieren alle davon!