Der Performancesprung bei Transfer Sizes ab 4k ist ja lustig
Naja, anyway! Bei allen Raidleveln, vorallem bei denen, die mit Parität arbeiten (z.B. 5 und 6), ist eine mehr oder weniger aufwendige Initialisierung notwendig. Das geschieht meistens im Hintergrund, während das Array schon "online" ist. Das siehst du auch in den Einstellungen ganz unten beim Punkt Background Initialization.
Der Controller bereitet dabei das Array sozusagen vor, man kann sich das ein wenig wie eine Formatierung vorstellen. Während er das macht kann man es aber bereits benutzen und Daten darauf schreiben.
Wenn die Initialisierung durch ist steigt normalerweise die Performance noch etwas an. Den Status zur Initialisierung findest du irgendwo in der Managementsoftware.
Die Read Policy kannst du auf Adaptive stellen, Always Read Ahead ist nicht immer ein Vorteil. Im Zweifelsfall mal ausprobieren!
Bei der Write Policy bietet sich Always Write Back an, so wie es im Moment eingestellt ist werden Schreibzugriffe nur mit angeschlossener BBU gecached. Zu der BBU hat jeder seine eigene Meinung, ich bin kein Fan davon und halte sie sowieso für unsinnig, daher den Schreibcache mit Always Write Back aktivieren.
Bei der IO Policy wird es vermutlich neben Direct IO auch noch Queued IO und/oder Cached IO geben. Da könntest du mal ein wenig mit experimentieren ob eine Umstellung irgendwas bringt. 100% sicher wäre ich mir dabei nicht, vermutlich könnten die anderen Einstellung je nach Nutzungsszenario interessant werden.
Für einen einfachen Fileserver reicht aber wohl die Standardeinstellung, was vermutlich Direct IO ist.
Bei der Access Policy kannst du festlegen wie Zugriffe priorisiert werden würde ich vermuten, das dürfte bei den wenigen parallelen Zugriffen in einer Heimumgebung egal sein.
Disk Cache Policy dürfte der Ein/Aus Schalter für den Cache der Platten sein, sollte man imho definitiv Enabled lassen.
