Also das mit dem Rebuild bei (theoretisch) 8 Platten in einerm RAID5 seh ich jetzt nicht so - der Rebuild dauert doch theoretisch so lange wie es dauert eine einzele Platte im gesamten Verbund zu schreiben/lesen (vorausgesetzt es sind alle 8 Platten gleich groß, aber das würde ich jetzt doch einmal annehmen). Er kann ja immer alle 7 Platten gleichzeitig lesen und dann auf die 8. schreiben. Sofern das gleichzeitige Lesen und Parity berechnen für 8 Platten nicht wesentlich länger dauert als bei 5 Platten sollte das genauso schnell gehen wie bei 5 Platten und sollte idealerweise nur von der Lese/Schreibgeschwindikeit der langsamsten Platte im Verbund abhängen (jede darüber hinausgehende Verlangsamung wäre meiner Meinung nach nur vom Chip verursacht und nicht von der Lese/Schreibgeschwindigkeit der Platten).
Natürlich wäre die Datensicherheit nicht so groß wie bei einem RAID5 mit 4 oder 5 Platten, aber immer noch weit besser als bei irgendeinem RAID0 oder JBOD wo alles weg ist, wenn nur eine ausfällt (und dass 2 gleichzeitig ausfallen ist auch bei 8 Stück eher unwahrscheinlich).
Aber egal, vielleicht kommt das dann ja mit der nächsten Modellreihe, bei RAID5 mit 8 Platten und Sleep Mode wäre ich jedenfalls dabei
Wegen dem Löschen:
Bei mir ist der Papierkorb auch "deaktiviert" - also es wird nicht in den Papierkorb verschoben sondern gleich gelöscht. Offenbar macht aber genau das das Problem noch gravierender. Denn wenn man in den Papierkorb verschiebt dann passiert nichts, dann laufen die Platten nicht an - erst wenn man ihn entleert dann laufen sie an.
Wenn man den Papierkorb aber deaktiviert hat und gleich löscht, dann macht Windows das intern offenbar so, dass der Papierkorb gleich immer geleert wird. Und dann hat man eben bei JEDEM Löschvorgang das Spiel, dass die Platten anlaufen
Wenn man diesen Mist-Papierkorb gänzlich deaktivieren könnte und Dateien so wie früher einfach "normal löschen", dann gäbe es das Problem nicht - aber offenbar geht das zumindest in Windows 7 nicht
