Medienserver verhindert (neuerdings) Systemruhezustand.

[rstle]

Woher hast Du das mit den 10 min. und vor allem wozu das?
Das Protokollschreiben dauert paar ms.
Wer in der Kiste den Vorgang auslöst ist mir letztlich egal.
Es dauert weniger als eine Sekunde den Spinndown auszulösen (nicht komplett abzuschließen, weil:
die Platten dann noch einige Zeit länger Strom brauchen, da ev. Schreibereien noch abgeschlossen werden müssen,
dann die Köpfe in Parkposition fahren und dann Abschaltung. Aber auch das sind nur ca. 10 Sekunden.
Letzten Endes ist das aber egal. Muß der Hersteller lösen.
Ich habe nichts von Protokollen, die nicht verfügbar sind.
Wie will ich z. B. dann einen Fehler wie jetzt hier, daß die Kiste nicht komplett schlafen geht, finden wenn der Auslöser für den Spinnoff nicht protokolliert wird?
Wobei mit Spinnoff sind wir eigentlich beide falsch, Spinnoff ist bei grün Blau ist kompletter Tiefschlaf.
Warten wir mal Herrn Fritz ab was da zurück kommt. Denn auch da kann man keine Pakete mehr lesen weil FW fehlerhaft.

 

[Puppetmaster]

Kann es sein, dass du hier etwas einfach nicht verstehst?

 

[rstle]

Durchaus möglich, dann klär mich auf.
Oder ev. umgekehrt?

 

[Puppetmaster]

Beantworte doch erst einmal die obige Frage, ob du denn weißt, ob die DS die Platte per hdparm etc. steuert, oder ob tatsächlich eine direkte Initiierung des Ruhezustands durch den DSM erfolgt (erfolgen kann).

 

[peterhoffmann]

Thema hdparm:
Ich habe gerade mal grob drübergeschaut. Leider habe ich keine Option gefunden, womit man die eingestellte Standby-Zeit auslesen kann. Damit wäre es wunderbar feststellbar gewesen, ob das DSM per hdparm den Wert für die Standbyzeit festlegt.

Aber schauen wir uns mal die Parameter für -S an:

Values from 1 to 240 specify multiples of 5 seconds, yielding timeouts from 5 seconds to 20 minutes. Values from 241 to 251 specify from 1 to 11 units of 30 minutes, yielding timeouts from 30 minutes to 5.5 hours. A value of 252 signifies a timeout of 21 minutes. A value of 253 sets a vendor-defined timeout period between 8 and 12 hours, and the value 254 is reserved. 255 is interpreted as 21 minutes plus 15 seconds. Note that some older drives may have very different interpretations of these values.

Wenn man diese Möglichkeiten nun mit den angebotenen Zeitwerten vom Dropdown unter "Systemsteuerung => Hardware/Energie = Ruhezustand der HDDs" vergleicht, nährt das den Verdacht, dass das DSM wirklich hdparm für diese Einstellung nutzt.
Es gibt aber auch einen Befehl (-y), der die HDD sofort in den Standby schickt. Das liest sich zuerst einfacher, aber wird wohl nicht die Vorgehensweise sein, da das DSM dann entscheiden müsste, wann es die HDDs in den Schlaf schickt. Das wäre viel zu kompliziert und zu unsicher.
So überlässt man es der Elektronik der HDDs. Ist im eingestellten Zeitraum kein Zugriff mehr erfolgt, geht sie schlafen. So umgeht man auch Probleme, dass ein Script wilde Sau spielt.

Und damit erklärt sich auch, warum kein Log mehr kurz vorm Schlafen geschrieben werden kann.
Wobei es mir rätselhaft ist, warum noch etwas ins Log geschrieben werden sollte. Das sie schlafen gehen?!

Interessanter wäre doch zu wissen was die HDDs aufgeweckt hat. Und das stelle ich mir kompliziert vor, da hier zu viele Dinge Zugriff auf die HDDs haben.

 

[rstle]

Kann ich aber nicht so ganz nachvollziehen. Wenn es wirklich hdparm (allein) wäre und dies Zugriffsabhängig, müßte die Platte ja ständig in Ruhe gehen, wenn die Kiste läuft und keiner macht was.
Es muß schon der Anstoß vom DSM kommen, denn darin werden ja auch die Zeiten eingestellt. Hdparm ist eigentlich ein Konsolenprogramm, nichts mit Oberfläche.
Vielleicht übergibt DSM dann an hdparm.
Dazu wäre ein Protokoll nicht übel, aber das gibst ja leider nicht.
Aber es geht ja nicht nur um HD Ruhe = grün - das funktioniert ja, sondern den Tiefschlaf.
Also kann es hdparm in dem Fall nicht sein, denn das steuert wenn überhaupt nur die HD und selbst die sicher nicht ganz allein.

 

[Puppetmaster]

Der Systemruhezustand kann aber erst greifen nachdem der Plattespindown gegriffen hat.
So stellte du es ja auch im DSM ein. Hdparm ist im Übrigen genauso ein Kosolenprogramm wie z.B. ntpd o.ä. Das kannst du aber alles auch über die GUI steuern,wenn du willst.

 

[rstle]

Stimmt, aber trotzdem müssen wir ja unterscheiden zwischen HD Ruhe und Tiefschlaf.
HD Ruhe ist sozusagen Vorläufer von Tiefschlaf, zumindest wenn ich Herrn Synology diesbezüglich richtig gelesen habe.
Aber auch dann kann das hdparm nicht alleine, denn es müßte noch die LED angesteuert werden, gut könnte im Quittunsgsignal von hdparm an DSM stecken
und was die gesamte Elektronik macht , ob da noch Bestandteile in Teil-Ruhestand gehen...
HD Ruhe tritt aber auch erst nach einer im DSM eingestellten Zeit ein, also eine Und Verknüpfung.

 

[Puppetmaster]

Wird mir jetzt zu kompliziert.
Jedes 0815 Gehäuse kann per LED den Zustand der Platten signalisieren. Ist auch gar nicht Thema hier, wie das elektronisch geregelt ist.
Annahme ist jedenfalls: über die GUI legst du den Zeitparameter für hdparm fest, dieser wird an die Platte ausgeliefert. Ende.
Danach wird jedweder Plattenzugriff den Countdown bis zum Spindown neu starten, exakt so wie bei externen Gehäusen.

Weshalb der Systemruhezustand dann nicht greift, keine Ahnung. Das hat Synology wohl verbockt.

 

[rstle]

Nix kompliziert, nur wir wissen es beide nicht, da fehlt eben das Protokoll mal an der entscheidenen Stelle.
Ansonsten sind wir beide völlig konform.
Ich hab auch keine Lust, noch dazu bei viel warm in den Untiefen zu kramen.
AVM und Synology müssen Hausaufgaben machen, denn die haben es verbockt

 

[Puppetmaster]

Oder du schaltest den Ruhezustand einfach ab und genießt einfach mal das viele "warm".

 

[rstle]

Viel warm bekommt mir nicht.
Ansonsten will ich nur das wofür ich bezahlt habe, Ruhe(zu)stand im doppelten Sinn.
Aber das wird jetzt wohl wirklich schwierig, zumindest das mit (zu).

 

[Puppetmaster]

Das Problem ganz allgemein: man hat selten genug bezahlt für das, was man wirklich will.

Das waren meine Gedanken zur Nacht.
Klinke mich jetzt aus hier.

 

[nachon]

Wenn es AVM wäre, müsste es dann nicht auch bei alten DSM Versionen ebenfalls schiefgehen?

Bei mir funktioniert der Systemruhezustand noch wie er soll. Ich arbeite aber auch noch auf der DSM 5.2.
Den Medienserver habe ich ebenfalls aktiv und nutze diesen fast ausschliesslich auf der DS 213+.

 

[rstle]

Das freut mich für Dich. Aber DSM 5.2 ist ja nun auch schon etwas älter.
Mir gefiel es auch optisch besser, ist aber auch unsicher.
Fakt ist jedoch, daß es bis zur Vorgänger FW Version der Fritzboxen funktionierte.
Ich habe es mit 7270,7390 und 7490 getestet, da läuft es auch mit der neuesten Synology FW.
immer vorausgesetzt die FB läuft nicht mit 6.83
Und nicht das wir uns mißverstehen, Du meinst mit Systemruhestand blaue LED atmet?
Herr Fritz hat mir heute geantwortet, es liegt natürlich wieder nicht an AVM sondern an Synology.
Gleiche Antwort bekam ich kürzlich, als die alte FB Firmware 6.63 der FB in der Oberfläche so lahmte,
da lag es an meiner Konfig und keinesfalls an AVM.
Nur seltsam, das mit dem Update auf 6.83 das Problem behoben war und das nicht nur bei mir.
Synology hat noch nicht geantwortet, vermute aber gleiche Antwort wie AVM.
Ich kann natürlich auch den Medienserver ausschalten dann funktioniert es wieder.
Dann kann ich die Kiste aber auch gleich aus lassen.
AVM hat ja in der Servererkennung mächtig gebastelt in der neuen FW und da liegt wohl der Hund begraben.

 

[nachon]

Ob älter oder nicht.

Ja, ich meine die blaue LED die leuchtet bze "atmet", also den Systemruhezustand. Mit der 7490 von AVM und aktueller Firmware klappt das bei mir auf der 213+ wunderbar.
Wohlgemerkt mit DSM 5.2. Klar ist die älter, aber genau aus diesem Grund habe ich mich den Updates verweigert. Und Sicherheitslöcher werden hier auch gestopft.

Ich will ja auch niemanden anstacheln zurück zu gehen. Ich wollte bei der Fehlersuche helfen, weil ich mir denken kann, wenn es an AVM liegt, dann müssten doch alle Versionen ggf. betroffen sein. Nicht zwingend, aber vielleicht hilft es dennoch weiter.

 

[rstle]

Das hat mir sogar sehr geholfen danke,
von AVM kann ich wohl nichts erwarten, oder erst so spät, daß ich monatelang warten muß.
Also müßte ich versuchen auf 5.2 zurückzugehen (falls ich es noch habe), was aber mit Sicherheit nicht einfach wird.
Denn einfach die .pat einspielen dürfte da nicht reichen
Bin ein wenig raus aus solchen Geschichten. Meine letzte Bastelei war eine 106 zur 107 umrüsten.
Zumal dann ja wohl auch alle gespeicherten Daten auf der DS neu überspielt werden müssen.
Bei über 40000 Fotos (Indizierung) und TM Backups von 4 Macs ein Alptraum.
Dazu wird die ext. Backupplatte der Syno mit 5.2 wohl auch nicht funktionieren,
sodaß ich wirklich alles neu von einer von Syno völlig unabhängigen Platte zurückspielen müßte.

Hab sie mir aber schon mal vom FTP heruntergeladen

 

[jackzone]

Nabend zusammen,

gibt es was Neues zu diesem Problem?

VG jackzone

 

[rstle]

Noch nicht so ganz. Herr Fritz meinte nach Überprüfung der Daten, es müßte an IPv6 liegen.
Da ich das aber schon vorher abgeschaltet hatte, fällt das auch flach.
Die abschließenden Untersuchungen dauern noch 2 Wochen,
gleichzeitig wird auf ein kommendes Update verwiesen....

Synology möchte einen Support-Fernzugriff und dazu meine Adminzugangsdaten, das ist mir ein wenig riskant.
Ist zwar nichts Schlimmes drauf, aber diverse Daten möchte ich nicht einfach freigeben.
Die Frage ist auch, wie kommt Synology durch den Router rein. Ich habe die Kiste derzeit nicht im Internet laufen.

 

[jackzone]

Ok, verstehe. IPv6 läuft bei mir ebenfalls nicht. Das DSM habe ich auf die aktuelle 6.0.3-8754-1 (die 6.1 lasse ich im Moment noch außen vor) und auch die Pakete (u. a. den Medienserver) aktualisiert. Das Problem mit dem nicht funktionierenden Systemruhezustand bleibt allerdings.

Ich befürchte, dass ein Fritz!OS-Update für die 7390 noch lange auf sich warten lässt.

Gruß jackzone