Nummer Serie DS413 - Kein System Hibernation Deep Sleep nach Update auf 4.2 Final

[alquanto]

Nein, ist es mir nicht.

Allerdings weiss ich nicht, welches Debug-Tool du meinst. Ich meine:
syno_hibernate_debug_tool --enable 10 Auf der Konsole.

welches ich eine zeit lang anschmeisse und gemäß diesem Link dann wieder deaktiviere.

und mit "log anschauen" meinte ich eher ein cat /var/log/messages | grep -A 3 modules/disk_hibernation

Sorry, habe mich ein wenig missverständlich ausgedrückt.

 

[Puppetmaster]

Ich meine:
syno_hibernate_debug_tool --enable 10 Auf der Konsole.

Genau das. Viele wissen nicht, dass mit laufendem Tool kein Ruhezustand möglich ist und es wird erst sehr spät klar, dass die ganze Zeit das debug-Tool lief.

 

[alquanto]

OK.
Und was tue ich jetzt?
a) das tool deaktivieren. Prima.
b) Warten, bis das NAS schläfrig wird - und hoffentlich einschläft. Und schlafen bleibt. Oder auch nicht.
c) Hinterher /var/log/messages durchwühlen

Korrekt?

 

[Puppetmaster]

Kann ich dir leider auch nicht sagen. Der System-Ruhezustand der DS213+/DS413 ist eine Baustelle. Bei dem einen geht's, beim anderen nicht. Es gibt anscheinend sehr viele Umstände, die die DS vom Schlafen abhalten. Ich persönlich investiere da vorerst keine Zeit mehr in eine Ursachenforschung.

Das Tool kannst du nutzen, um ein aussagekräftigeres Log zu erhalten. Möglicherweise entdeckst du den oder die Schuldigen. Aber es kann auch sein, dass du nachher so schlau wie zuvor bist.
Im Zweifel, und wenn du Zeit und Muße zur Ursachenforschung hast, dann machst du ein Ticket beim Support auf und klagst denen dein Leid. Irgendwann wird es Synology dann wohl auch bewußt werden, dass dieser Ruhezustand alles andere als rund läuft.

 

[alquanto]

Hey,

ich schaue mir das mal in einer ruhigen Minute an. Wie gesagt, es sind ENORM wenig Dienste angeknipst. Und mit der 4.1 funktionierte DeepSleep zuverlässig.

 

[Bold]

Dann würde ich mal die Peripherie Checken.

1. Alle Dienste inkl. NTP deaktivieren
2. LAN-Kabel entfernen

? Haken bei Broadcast Pakete von Windows ignorieren gesetzt?

Danke für die schnelle Antwort, wie es aussieht könnte es an nicht aktiverten "Broadcast Pakete von Windows ignorieren gesetzt" gelegen haben.
Habe alles mögliche deaktivert und auch einiges wieder aktiviert, jedenfalls gehts jetz. Nur ist sie nach kurzer Zeit wieder aufgewacht, das muss ich mal noch weiter beobachten.

 

[Evia]

Hibernation bei der DS213 mit DSM4.2

Ich habe auf meiner DS213+ den Patch eingespielt, weil nach dem Update auf 4.2 sie sich immer nur für ein Paar Sekunden schlafen legte und dann wieder aufwachte. Zunächst sah alles toll aus. Dann aber stellte sich das alte Phänomen ein...
Nachdem ich mir mal die Logs angeschaut habe kommt der Verdacht auf, dass das Problem durch die Zeitsynchronisierung verursacht wird. Ich habe sehr viele Logeinträge dass die Synchronisierung fehlgeschlagen ist. Ich habe nun die Synchronisierung abgeschaltet und habe im Moment Ruhe. (Damit meine ich dass die DS sich schlafen gelegt hat...) mal sehen was heute Nacht ist....

Darüber hinaus, hat sich nach dem Patch die Situation eingestellt, dass wenn sie denn mal in den Hibernate Modus ist, sie sich nicht mehr durch meinen iMac "Wecken" lässt. Ich muss erst ueberlesen das Webinterface drauf zugreifen. Dann kann ich nach ca. 20sec auch auf die Platten zugreifen.
Ich glaube dass der Patch die Situation verschlimmbessert hat :-(

 

[alquanto]

Situation: DS413 mit eingespieltem Patch. Hat die Nacht im Schlaflabor verbracht.

Heute Morgen fand ich es dann schlafend vor. Prima.
Ich habe mir daraufhin das Log angeschaut.
Ergebnis: nachdem der Streamer wie auch alle anderen Rechner ausgeschaltet wurden, fand ich dann dies in /var/log/messages:

Mar 25 20:23:48 afpd[12784]: [afp_dsi.c:366-E] afp_alarm: child timed out, entering disconnected state

Prima.
Ich verwende nur AFP als Freigabedienst, da ich nur Macs im Netz habe.
Das Ausknipsen des Streamers hatte diesen Eintrag zur Folge. Default für ein AFPd-Timeout sind übrigens 120 Sekunden. Dann:

Mar 25 20:39:54 scemd: SCEMD: disk 4 wake up from hibernation
Mar 25 20:40:14 ntpdate: Sync with time server 193.175.73.151 offset 0.839358 sec.
Mar 25 20:40:14 scemd: SCEMD: disk 1 wake up from hibernation
...

Nanü? Warum? Es griff niemand mehr auf die Kiste zu. Alle Geräte waren ausgeschaltet ausser dem Router - aber der macht keinen Mucks.
Theorie: das NAS muss gerade eingeschlafen sein (15 Minuten timeout), um dann wieder eine Minute später aufgeweckt zu werden. Super übrigens für die Festplatten.
Und weiter:

Mar 25 20:57:58 scemd: modules/disk_hibernation.c:2356 Diskstation wakes up from deep sleep.
Mar 25 20:58:06 ntpdate: Sync with time server 62.116.162.126 offset 1.329521 sec.
Mar 25 21:17:17 kernel: [28997.512095] ata1: wake up from deepsleep, reset link now
...
Mar 25 21:18:06 scemd: modules/disk_hibernation.c:2349 Diskstation wakes up from sys sleep.

Anscheinend ging das NAS nach meinem 15minütigen Timeout wieder schlafen, denn die nächste Zeilen sind diese:

Mar 26 04:18:26 ntpdate: Sync with time server 85.10.246.229 offset 25211.871035 sec.
...
Mar 26 04:19:13 crond[5118]: crond: time disparity of 421 minutes detected
Mar 26 04:35:58 kernel: [30107.370330] ata1: wake up from deepsleep, reset link now
...
Mar 26 04:36:08 scemd: modules/disk_hibernation.c:2356 Diskstation wakes up from deep sleep.
...
Mar 26 04:36:43 ntpdate: Sync with time server 46.4.54.78 offset 0.339152 sec.
...
Mar 26 04:56:46 scemd: modules/disk_hibernation.c:2349 Diskstation wakes up from sys sleep.

Heute morgen gegen 8 habe ich das System durch einloggen via SSH aufgeweckt. Die einzige Zeile, die im Log daraufhin auftaucht ist diese hier:

Mar 26 08:07:19 ntpdate: Sync with time server 131.188.3.221 offset 11425.620513 sec.

Anscheinend wird der Hibernation-Vorgang - also das Einschlafen - selbst nicht mitgeloggt. OK.

Aber warum muss das NAS trotz eingespieltem Patch Nachts die Uhrzeit aktualisieren? - Verstehe ich nicht.

Zur Info:
alle Dienste aus, nur AFP ist an.
Systemsteuerung -> Regionale Optionen -> Zeiteinstellung -> "Mit einem Zeitserver synchronisieren" ist angeknipst
Systemsteuerung -> Regionale Optionen -> "NTP Dienst" ist aus.
Systemsteuerung -> Hardware -> Ruhezustand:
"Systemruhezustand 60 Sekunden nach HDD Ruhezustand aktivieren" ist angehakt.
"Broadcasting Pakete von Windows Explorer ignorieren" ist auch angehakt, obwohl hier kein Windows residiert.

 

[alquanto]

Habe noch mal genau geschaut:

ntpdate ist hundertprozentig der Schuldige. Ob das jetzt daran liegt, dass ich den Timeout auf 15 Minuten eingestellt habe (anstelle der 20 Minuten default) weiss ich nicht, aber nachdem ich mit der Stoppuhr daneben gestanden habe ist Folgendes passiert:

Genau 15 Minuten nach dem letzten Zugriff hat das NAS die Platten herunter gefahren. Alle LEDs waren aus ausser der Status-LED, die langsam grün blinkte (kann man das An- und Abschwellen "Blinken" nennen?).
Wohlgemerkt - die blaue LED blinkte NICHT.

5 Sekunden später wurden die Platten wieder hochgefahren und das Teil war wieder an. In /var/log/messages stand lediglich:

Mar 26 10:10:18 ntpdate: Sync with time server 141.22.13.9 offset 1.459757 sec.
Mar 26 10:10:18 scemd: SCEMD: disk 1 wake up from hibernation
Mar 26 10:10:18 scemd: SCEMD: disk 2 wake up from hibernation
Mar 26 10:10:18 scemd: SCEMD: disk 3 wake up from hibernation
Mar 26 10:10:18 scemd: SCEMD: disk 4 wake up from hibernation

Aha.

Das sollte doch für einen vernünftigen Bugfix reichen, oder?

 

[Frogman]

Und was passiert, wenn Du den Time-Sync (der vermutlich das ntpdate nutzt) deaktivierst und dagegen die Time-Server-Funktion aktivierst? (der laufende ntpd hält die Zeit dann soweit ja auch aktuell)

 

[hakiri]

Gibt es bei Euch noch News?
Ich habe nach wie vor nur den Modus an, wo die Platten sich schlafen legen und dies funktioniert i.d.R.
Manchmal ist es noch so, dass morgens, wenn ich nachm Aufstehen mal hinschaue, die Platten aktiv sind. Meist sind sie jedoch aus.
Automatischer Time Sync ist bei mir aus.

 

[Kommerzialrat]

Nach dem mediaserver Update von gestern weiterhin keine Probleme. Ich muss nur das System einmal pro Nacht wecken, damit ich immer auf ddns zugreifen kann.

 

[alquanto]

Sodele.

Ich habe auf das NAS jetzt seit 2,5 Tagen nicht zugegriffen

Auch ohne mein Zutun wacht die DS413 eigenständig nachts auf - obwohl kein Gerät darauf zugreift und/oder aus ist:
Mar 29 04:18:46 ntpdate: Sync with time server 46.165.212.204 offset 152523.105280 sec.
...
Mar 29 04:35:50 ntpdate: Sync with time server 217.79.179.106 offset 1.216664 sec.
...
Mar 29 04:53:20 scemd: modules/disk_hibernation.c:2356 Diskstation wakes up from deep sleep.
...
Mar 29 04:53:48 ntpdate: Sync with time server 5.9.89.201 offset 0.407942 sec.

Warum auch immer. Interessanterweise blieb das NAS allerdings einen Tag aus laut log - siehe den großen Offset in der ersten Zeile. Strange.
Beide Tage waren alle anderen Geräte (ausser Router) aus.

Jetzt habe ich Folgendes geändert:
Systemsteuerung -> Regionale Optionen -> Zeiteinstellung -> "Manuell" ist angeknipst
Systemsteuerung -> Regionale Optionen -> "NTP Dienst" ist an.

Mal sehen, was passiert.

 

[hakiri]

Ich habe nun auch mal Deep Standby angemacht. Wie gesagt, ZeitSync hatte ich komplett aus. Also manuell und kein NTPD.
Sieht alles sehr strange aus mein Log.

Mar 29 10:03:44 kernel: [496850.432786] ata2: link reset sucessfully clear error flags
Mar 29 11:08:37 kernel: [500705.075455] Freezing user space processes ... (elapsed 0.00 seconds) done.
Mar 29 11:08:37 kernel: [500705.089074] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
Mar 29 11:08:37 kernel: [500705.100044] Suspending console(s) (use no_console_suspend to debug)
Mar 29 11:08:37 kernel: [500705.107759] ata6: send port disabled event
Mar 29 11:08:37 kernel: [500705.113657] ata5: send port disabled event
Mar 29 11:08:37 kernel: [500705.318974] ata1: send port disabled event
Mar 29 11:08:37 kernel: [500705.319009] ata2: send port disabled event
Mar 29 11:08:37 kernel: [500705.319036] ata3: send port disabled event
Mar 29 11:08:37 kernel: [500705.319063] ata4: send port disabled event
Mar 29 11:08:37 kernel: [500705.330830] Disabling non-boot CPUs ...
Mar 29 11:08:37 kernel: [500705.883159] Enabling non-boot CPUs ...
Mar 29 11:08:37 kernel: [500705.883187] setting frequency for cpu 0 to 1066666 kHz, PLL ratio is 4/2
Mar 29 11:08:37 kernel: [500705.883195] PMJCR request 04043c00 at CPU 0
Mar 29 11:08:37 kernel: [500705.883202] PORPLLSR core freq 1066MHz at CPU 0
Mar 29 11:08:37 kernel: [500705.883928] Processor 1 found.
Mar 29 11:08:37 kernel: [500705.994616] 0: 533333kHz
Mar 29 11:08:37 kernel: [500705.994620] 1: 799999kHz
Mar 29 11:08:37 kernel: [500705.994623] 2: 1066666kHz
Mar 29 11:08:37 kernel: [500705.994627] 3: 1333332kHz
Mar 29 11:08:37 kernel: [500705.994631] 4: 1599999kHz
Mar 29 11:08:37 kernel: [500705.994634] 5: 1866665kHz
Mar 29 11:08:37 kernel: [500705.994638] 6: 2133332kHz
Mar 29 11:08:37 kernel: [500705.994684] setting frequency for cpu 1 to 1066666 kHz, PLL ratio is 4/2
Mar 29 11:08:37 kernel: [500705.994690] PMJCR request 04043c00 at CPU 1
Mar 29 11:08:37 kernel: [500705.994695] PORPLLSR core freq 1066MHz at CPU 1
Mar 29 11:08:37 kernel: [500705.994728] setting frequency for cpu 1 to 1066666 kHz, PLL ratio is 4/2
Mar 29 11:08:37 kernel: [500705.994734] PMJCR request 04043c00 at CPU 1
Mar 29 11:08:37 kernel: [500705.994739] PORPLLSR core freq 1066MHz at CPU 1
Mar 29 11:08:37 kernel: [500705.994744] CPU1 is up
Mar 29 11:08:37 kernel: [500709.006581] ata1: wake up from deepsleep, reset link now
Mar 29 11:08:37 kernel: [500710.523509] ata6: No Device OR PHYRDY change,Hstatus = 0xa0000000
Mar 29 11:08:37 kernel: [500710.523540] ata5: No Device OR PHYRDY change,Hstatus = 0xa0000000
Mar 29 11:08:37 kernel: [500716.010510] ata3: wake up from deepsleep, reset link now
Mar 29 11:08:37 kernel: [500717.495508] ata1: link is slow to respond, please be patient (ready=0)
Mar 29 11:08:37 kernel: [500722.030508] ata1: SRST failed (errno=-16)
Mar 29 11:08:37 kernel: [500722.030513] ata1: SRST fail, set srst fail flag
Mar 29 11:08:37 kernel: [500722.562542] ata1: link reset sucessfully clear error flags
Mar 29 11:08:37 kernel: [500723.014503] ata4: wake up from deepsleep, reset link now
Mar 29 11:08:37 kernel: [500724.499508] ata3: link is slow to respond, please be patient (ready=0)
Mar 29 11:08:37 kernel: [500729.038505] ata3: SRST failed (errno=-16)
Mar 29 11:08:37 kernel: [500729.038510] ata3: SRST fail, set srst fail flag
Mar 29 11:08:37 kernel: [500729.570537] ata3: link reset sucessfully clear error flags
Mar 29 11:08:37 kernel: [500730.018504] ata2: wake up from deepsleep, reset link now
Mar 29 11:08:37 kernel: [500731.503508] ata4: link is slow to respond, please be patient (ready=0)
Mar 29 11:08:37 kernel: [500736.042504] ata4: SRST failed (errno=-16)
Mar 29 11:08:37 kernel: [500736.042509] ata4: SRST fail, set srst fail flag
Mar 29 11:08:37 kernel: [500738.366538] ata4: link reset sucessfully clear error flags
Mar 29 11:08:37 kernel: [500738.506502] ata2: link is slow to respond, please be patient (ready=0)
Mar 29 11:08:37 kernel: [500743.042502] ata2: SRST failed (errno=-16)
Mar 29 11:08:37 kernel: [500743.042507] ata2: SRST fail, set srst fail flag
Mar 29 11:08:37 kernel: [500743.518537] ata2: link reset sucessfully clear error flags
Mar 29 11:08:37 kernel: [500743.924830] Restarting tasks ... done.
Mar 29 11:08:37 scemd: modules/disk_hibernation.c:381 Fail to insert the usb module: ehci_hcd
Mar 29 11:08:38 scemd: modules/disk_hibernation.c:384 Fail to insert the usb module: ohci_hcd
Mar 29 11:08:39 kernel: [500745.121533] usb usb2: No SuperSpeed endpoint companion for config 1 interface 0 altsetting 0 ep 129: using minimum values
Mar 29 11:08:39 scemd: modules/disk_hibernation.c:387 Fail to insert the usb module: xhci_hcd
Mar 29 11:08:39 scemd: modules/disk_hibernation.c:390 Fail to insert the usb module: etxhci_hcd
Mar 29 11:08:39 scemd: modules/disk_hibernation.c:2349 Diskstation wakes up from sys sleep.
Mar 29 11:09:18 scemd: modules/fan_check_common.c:601 Start fan full speed to avoid fan fail
Mar 29 11:09:24 scemd: modules/fan_check_common.c:605 Stop fan full speed to avoid fan fail

 

[alquanto]

Nach Deaktivieren des TimeSyncs und Aktivieren des NTPds sieht das Ganze jetzt so aus:

- Das NAS geht brav schlafen und hat die Nacht ohne Unterbrechung durchschlafen.
- Gestern Abend ist es noch einmal aufgewacht. Hier frage ich mich: ich habe mein Notebook angeschaltet zu dem Zeitpunkt, aber das NAS hatte ich definitiv nicht gemountet. Sollte ich wohl mal genauer debuggen...

Hier ein Auszug aus /var/log/messages:
Mar 29 13:33:05 scemd: modules/rtc.c:238 RTC and system time diff are too large. rtc_year:[113] rtc_mon:[2] rtc_mday:[29] rtc_hour:[18] sys_year:[113] sys_mon:[2] sys_mday:[29] sys_hour:[12] timezone:[-3600]
Mar 29 13:33:09 scemd: modules/rtc.c:238 RTC and system time diff are too large. rtc_year:[113] rtc_mon:[2] rtc_mday:[29] rtc_hour:[18] sys_year:[113] sys_mon:[2] sys_mday:[29] sys_hour:[12] timezone:[-3600]
Mar 29 13:33:09 scemd: modules/rtc.c:256 RTC looks like fine, maybe system error let it update
Mar 29 19:05:54 scemd: modules/fan_check_common.c:601 Start fan full speed to avoid fan fail
Mar 29 19:06:00 scemd: modules/fan_check_common.c:605 Stop fan full speed to avoid fan fail
Mar 29 19:06:45 crond[5118]: crond: time disparity of 333 minutes detected
...
Mar 29 19:25:47 scemd: modules/disk_hibernation.c:2349 Diskstation wakes up from sys sleep.
... (Kernel Meldungen)
Mar 29 19:25:48 scemd: modules/rtc.c:238 RTC and system time diff are too large. rtc_year:[113] rtc_mon:[2] rtc_mday:[30] rtc_hour:[7] sys_year:[113] sys_mon:[2] sys_mday:[29] sys_hour:[18] timezone:[-3600]
Mar 29 19:25:52 scemd: modules/rtc.c:238 RTC and system time diff are too large. rtc_year:[113] rtc_mon:[2] rtc_mday:[30] rtc_hour:[7] sys_year:[113] sys_mon:[2] sys_mday:[29] sys_hour:[18] timezone:[-3600]
Mar 29 19:25:52 scemd: modules/rtc.c:256 RTC looks like fine, maybe system error let it update
Mar 30 08:30:34 scemd: modules/fan_check_common.c:601 Start fan full speed to avoid fan fail
Mar 30 08:30:40 scemd: modules/fan_check_common.c:605 Stop fan full speed to avoid fan fail
Mar 30 08:30:42 crond[5118]: crond: time disparity of 785 minutes detected

Also:
- weniger häufiges Aufwachen - gut!
- ntpdate taucht nicht mehr auf. Trotzdem würde ich diese Alternative bevorzugen, da ich keinen NTP lokal benötige und stattdessen ein genau tickendes NAS hätte
Und die Tatsache, dass um 8:30 jetzt die Lüfter durchgeblasen werden liegt daran, dass ich per SSH mir das Log angeschaut habe. Das hat das NAS aufgeweckt.

Hilft das dem Support?

 

[alquanto]

Ich habe zwar keine Ahnung, aber vielleicht eine Vermutung:

Ich habe nun auch mal Deep Standby angemacht. Wie gesagt, ZeitSync hatte ich komplett aus. Also manuell und kein NTPD.
Sieht alles sehr strange aus mein Log.

Mar 29 10:03:44 kernel: [496850.432786] ata2: link reset sucessfully clear error flags
Mar 29 11:08:37 kernel: [500705.075455] Freezing user space processes ... (elapsed 0.00 seconds) done.
Mar 29 11:08:37 kernel: [500705.089074] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
Mar 29 11:08:37 kernel: [500705.100044] Suspending console(s) (use no_console_suspend to debug)
Mar 29 11:08:37 kernel: [500705.107759] ata6: send port disabled event
Mar 29 11:08:37 kernel: [500705.113657] ata5: send port disabled event
Mar 29 11:08:37 kernel: [500705.318974] ata1: send port disabled event
Mar 29 11:08:37 kernel: [500705.319009] ata2: send port disabled event
Mar 29 11:08:37 kernel: [500705.319036] ata3: send port disabled event
Mar 29 11:08:37 kernel: [500705.319063] ata4: send port disabled event
Mar 29 11:08:37 kernel: [500705.330830] Disabling non-boot CPUs ...
Mar 29 11:08:37 kernel: [500705.883159] Enabling non-boot CPUs ...
...
Mar 29 11:08:39 scemd: modules/disk_hibernation.c:2349 Diskstation wakes up from sys sleep.
Mar 29 11:09:18 scemd: modules/fan_check_common.c:601 Start fan full speed to avoid fan fail
Mar 29 11:09:24 scemd: modules/fan_check_common.c:605 Stop fan full speed to avoid fan fail

Das habe ich auch. Ich interpretiere das so: die oberen Logeinträge sind wohl noch vom letzten Schlafen übriggeblieben und werden hier mitgeloggt - also alles bis "Disabling non-boot CPUs" - und danach geht's ans Aufwachen - also alles nach "Enabling non-boot CPUs" bis "Diskstation wakes up from sys sleep.".

Finde ich auch ein wenig merkwürdig, aber nungut.

 

[hakiri]

Habe noch etwas rausgefunden.
Wenn ein Rechner noch ein Samba Share offen hat zur NAS hin, dann geht die Kiste auch nicht in den StandBy. Nur Spin Down funktioniert.
Ich habe nämlich einen Sheevaplug mit Samba an meine Songs angebunden.

 

[alquanto]

Hallo,

Nachtrag zur Methode "schalte ntpdate ab und NTPd ein stattdessen": Prima - geht schlafen, aber nur wenn alle Shares sauber abgemeldet wurden. AFP-Timeout scheint keins mehr aufzutauchen.

Beispiel:
(Timeout = 15 Minuten für DeepSleep)
Medienstreamer via AFP an DS413 verbunden. Diesen dann Gestern Abend ausgeschaltet. Das NAS wacht wieder ein paar mal auf die Nacht, wohingegen der Streamer noch nicht mal mehr Strom hat. Schon echt unzuverlässig.

Und in der Web-UI sehe ich dann den Share als noch aktiv (seit gestern Abend)...

 

[till213]

Hey hey hey, ein neues Update der DSM v4.2 scheint es zu geben: DSM 4.2-3211 (2013/04/18)

http://www.synology.com/releaseNote_enu/DS413.php?lang=deu

Ich selbst bin ja immer noch auf v4.1. Kann da mal jemand bitte vorpreschen und schauen, was jetzt alles wieder (nicht mehr) tut?

Insbesondere der Hibernation Mode der DS 413 würde mich interessieren. Wobei sich die DS ja auch mit der DSM v4.1 mit angeschlossener USB 3 backup Platte weigert, in den Tiefschlafmodus zu gehen - auch das scheint ein bekanntes Problem zu sein. Meine Vermutung ist, das die DS die Platte immer gemounted hält, obwohl sie diese doch auch automatisch - nach einer gewissen Zeit - unmounten könnte und dann gefahrlos in den Tiefschlaf zu gehen.

Wäre also auch interessant, wie sich DSM 4.2 mit angehängter USB 3 Platte verhält.

Wer updated zuerst?

 

[Frogman]

Wer updated zuerst?

Immer der, der fragt

Aber es gibt ja auch inzwischen einen ersten Thread zur neuen 3211 - da tauchen dann bestimmt auch bald erste Wasserstandsmeldungen hierzu auf.