Die ZFS Sync Eigenschaft kennt drei Optionen
default (schreibendes Programm entscheidet)
always (immer mit write logging)
disabled (logging immer deaktiviert)
Wenn man bei einem Fileservice wie SMB oder iSCSI Logging erzwingt (bei default wird sync nicht genutzt) dann wird das Schreiben selbst mit dem schnellsten Logdevice langsamer da jede Schreibaktion zweimal ausgeführt wird, einmal bei jedem commit sofort auf das Logdevice und einmal wenn der Inhalt des Scheibcaches (Schreibcache bei ZFS ist RAM, per default - mit ausreichend RAM - sind das 4GB) sequentiell auf den Pool geschrieben wird.
Da ZFS selbst dank CopyOnWrite immer consistent ist (bei einer Schreibaktion ist immer gesichert dass auch bei Raid die Aktion komplett mit Daten und Metadaten auf dem Pool/Raid ist) ergibt sich nur ein minimaler Sicherheitsgewinn, nämlich dann wenn bei Schreiben einer kleinen Datei diese komplett im Schreibcache liegt (also komplett im Slog) aber noch nicht komplett aus dem Schreibcache auf den Pool geschrieben wurde. Das ist ein extrem kleines Zeitfenster das man damit zusätzlich absichern könnte. Deshalb ist sync=always für einen Fileserver mit SMB eigentlich wenig sinnvoll. Auch bei NFS wäre sync nicht sinnvoll wenn man damit reine ZFS Fileservices betreibt. Sind darauf allerdings VMs mit vmfs oder alten Dateisystemen z.B. mit ESXi wird sync essentiell da sonst schnell die Gefahr einer korrupten VM besteht. Vmfs, ext4, ntfs etc sind eben nicht transaktionssicher/ CopyOnWrite.
Normalerweise ist egal ob mit sync oder ohne die aktuell geschriebene Datei immer defekt wenn z.B. der Strom ausfällt. Das kann nur das schreibende Programm abfangen, z.B. mit einem temp-File des letzten Stands.
Wichtig ist sync nur bei Transaktionen, z.B. wenn alte Dateisysteme ohne CopyOnWrite beteiligt sind die keine sicheren atomaren Schreibaktionen können. Bei denen besteht jedes Write aus zwei abhängigen Aktionen.
1. Schreibe Daten
2. aktualisiere Metadaten
Wenn 1. ausgeführt wird und 2. nicht, ist das Dateisystem korrupt.
Ein anderes Beispiel ist eine Finanzumbuchung. Sie besteht aus einem Abbuchen von einem Konto und dem Aufbuchen auf ein anderes. Blöd wenn wegen einem Crash nur ersteres stattfindet. Das Geld ist dann im Datennirwana.
Genau für diese Fälle braucht man sync
default (schreibendes Programm entscheidet)
always (immer mit write logging)
disabled (logging immer deaktiviert)
Wenn man bei einem Fileservice wie SMB oder iSCSI Logging erzwingt (bei default wird sync nicht genutzt) dann wird das Schreiben selbst mit dem schnellsten Logdevice langsamer da jede Schreibaktion zweimal ausgeführt wird, einmal bei jedem commit sofort auf das Logdevice und einmal wenn der Inhalt des Scheibcaches (Schreibcache bei ZFS ist RAM, per default - mit ausreichend RAM - sind das 4GB) sequentiell auf den Pool geschrieben wird.
Da ZFS selbst dank CopyOnWrite immer consistent ist (bei einer Schreibaktion ist immer gesichert dass auch bei Raid die Aktion komplett mit Daten und Metadaten auf dem Pool/Raid ist) ergibt sich nur ein minimaler Sicherheitsgewinn, nämlich dann wenn bei Schreiben einer kleinen Datei diese komplett im Schreibcache liegt (also komplett im Slog) aber noch nicht komplett aus dem Schreibcache auf den Pool geschrieben wurde. Das ist ein extrem kleines Zeitfenster das man damit zusätzlich absichern könnte. Deshalb ist sync=always für einen Fileserver mit SMB eigentlich wenig sinnvoll. Auch bei NFS wäre sync nicht sinnvoll wenn man damit reine ZFS Fileservices betreibt. Sind darauf allerdings VMs mit vmfs oder alten Dateisystemen z.B. mit ESXi wird sync essentiell da sonst schnell die Gefahr einer korrupten VM besteht. Vmfs, ext4, ntfs etc sind eben nicht transaktionssicher/ CopyOnWrite.
Normalerweise ist egal ob mit sync oder ohne die aktuell geschriebene Datei immer defekt wenn z.B. der Strom ausfällt. Das kann nur das schreibende Programm abfangen, z.B. mit einem temp-File des letzten Stands.
Wichtig ist sync nur bei Transaktionen, z.B. wenn alte Dateisysteme ohne CopyOnWrite beteiligt sind die keine sicheren atomaren Schreibaktionen können. Bei denen besteht jedes Write aus zwei abhängigen Aktionen.
1. Schreibe Daten
2. aktualisiere Metadaten
Wenn 1. ausgeführt wird und 2. nicht, ist das Dateisystem korrupt.
Ein anderes Beispiel ist eine Finanzumbuchung. Sie besteht aus einem Abbuchen von einem Konto und dem Aufbuchen auf ein anderes. Blöd wenn wegen einem Crash nur ersteres stattfindet. Das Geld ist dann im Datennirwana.
Genau für diese Fälle braucht man sync
Zuletzt bearbeitet:
