Der Ruhezustand ist eine Eigenschaft der Platten, nicht der DS. Mit anderen Worten, es wird ein SCSI-Steuerkommando zum SATA-Controller der Platte geschickt, doch bitteschön nach xx Minuten die Ruhepause einzulegen. Daraufhin stellt sich der Plattencontroller einen Timer und wenn er bis zu der abgelaufenen Zeit nicht unterbrochen wird durch neue Aufgaben, legt er die Platte schlafen. Soviel zur Theorie.
Nun können zwei Dinge eintreten, die das verhindern:
(1) die Platte erhält laufend neue Aufträge (das ist das, was man mit dem Message-Protokoll halt versucht zu analysieren)
(2) die Benachrichtigung über den Ruhe-Zustands-Wunsch kann von der DS nicht an den Platten-Controller übermittelt werden, weil die Platte mal wieder irgendwelche neuen Kommando-Sequenzen hat oder der Controller solche Aufträge nur unter bestimmte Bedingungen entgegen nimmt (alles Caches geflusht oder die eingebaute Umdrehungsverlangsamung ausgeschaltet, weil die mit dem Spin-Down der Platte nicht harmoniert oder oder ...) Das ist das, was Synology bei jeder neuen Platte, die sie testen, versucht herauszubekommen und dann in die Firmware der DS einbauen. Bei manchen Platten ist das wohl ein unendlichens Problem.
Nun stellt sich immer erstmal die Frage, ist (1) der Grund für das Verhindern des Ruhezustands (bei 80% aller hier diskutierten Fälle der Fall
) oder ist (2) aufgrund der vielleicht noch ungetesteten Platte der Fall.
Um (1) auszuschließen, musst man die Prozeduren mit dem Kommando
syno_hibernate_debug_tool anlaufen lassen, die hier schon 100x diskutiert worden sind.
Wenn es daran nicht liegt, dann wendest dich am besten per Mail an den Synology-Support und fragt an, ob sie das Problem bearbeiten ... hier ins Forum schaut niemand von Synology hinein, das kannst dir also sparen, nachzufragen, wann das gefixt wird, weils eh keiner weiß.
itari
