Snyc writes fallen wohl auch bei async mounts an, z.B. beim erstellen neuer Dateien. Beiweitem nicht so viele wie bei sync mounts aber laut Nexenta ist ein ZIL auf jeden Fall hilfreich.
Wobei die SSDs ja auch erheblich besser mit sync writes zurechtkommen sollten als HDDs.
Die Aussage würde ich so nicht unterschreiben.
Es gibt keine sync mounts. Sync ist eine Eigenschaft des ZFS Dateisystems (oder via writeback cache eines Blockdevices) das das Verhalten beim Schreiben auf das Dateisystem steuert.
Wenn sync=default, so kann ein schreibender Prozess selbst entscheiden, ob er sync write möchte oder nicht. Bei SMB ist das nie der Fall, bei NFS häufig (ESXi=immer) Wenn man besonders kritische Sachen auf dem Dateisystem hat (z.B. Datenbanken) so kann man auch sync write generell einschalten.
Wenn man nur SMB macht, so macht sync wenig Sinn. Sync hat keine Auswirkungen auf die Konsistenz eines Dateisystems hat (ZFS ist immer konsistent). Prozesse wie der SMB Server fordern das gar nicht an. Sync bedeutet dass Schreibaktionen, die einem schreibenden Prozess als committed (ist auf Platte) gemeldet werden auch tatsächlich auf der Platte sind (oder bei Stromausfall wenigstens beim nächsten Start nachgeholt werden). Wichtig also bei Transaktionen oder falls "alte Dateisysteme" z.B. als virtuelle Platte betroffen sind. Jede Schreibaktion wird dazu erst ins schnelle ZIL device (on Pool oder idealerweise extra Slog device) protokolliert und dann nochmal als sequentielles Write über den Schreibcache auf den normalen Pool geschrieben.
Ist das nicht der Fall ist ein Slog device wie ein Kropf: unnötig, ja schädlich.
Es würde nur bei sync=always genutzt und würde dann als Schreibbremse arbeiten.
Zu dern "Selbstbaulösungen".
Wenn man sich bei den ZFS Lösungen, z.B. Nexenta umschaut, so wird man immer auf folgendes stoßen:
Supermicro Case + SuperMicro board + LSI HBA + Intel Nic. Es ist also nicht Selbstbau sondern es gibt einfach Standardlösungen für ZFS Storage die weltweit tausendfach im Einsatz sind.
Im Endeffekt ist es aber oft so, NetApp + Support, ZFS und günstig oder etwas dazwischen, dass dann oft deren Features wie Performance, Erweiterbarkeit, CopyOnWrite und Prüfsummen auf Daten nicht hat.
- - - Updated - - -
@Gea: wenn ich die Rechte auf einem Pool "neutralisieren" möchte, hatte ich bisher das Problem, das ich dies unter Windows nicht sauber bis auf den letzten Ordner hinbekommen habe. Diese vererbten Rechte usw. anderer Benutzer "klebten" dann doch fest. Habe es bisher nur so hinbekommen das ich einen neuen Pool anlegte und die Daten rüber kopiert habe.
Für so einen Schalter oder Script der die Rechte neutralisiert oder wo ich einfach nur die Rechte pro Ordner Freigeben kann, wäre ich äußerst dankbar. Ich habe jetzt nur wieder den Vergleich zu z.B. Xpenology, weiss aber auch nicht genau wie das da gelöst wird, ist nur halt recht simpel und einfach beim Handling.
Rechte rücksetzen bedeutet unter Windows:
- Als Administrator anmelden und erst rekursiv Eigentümer werden
- dann Rechte rekursiv zurücksetzen
Unter Unix ist der erste Schritt nicht notwendig, da root immer Zugriff hat, unabhängig von den Eigentümer-Einstellungen
Rücksetzen auf jeder darf, geht mit napp-it folgendermassen
Im Menu ZFS Dateisystems in der Spalte ACL on Folders auf das Dateisystem klicken.
Es werden dann die ACL des Dateisystems angezeigt.
Unter der Rechteauflistung kann man ACL Einstellungen ändern (Teilweise nur mit napp-it Pro).
Der Menüpunkt "reset ACLs" rekursive auf everyone@=modify ist aber immer verfügbar.
