Syncthing auf Unraid langsam? Wie /mnt/user und fsync den Abgleich um Faktor 110 bremsen

Zwei Stunden nach dem Start des Erstabgleichs sah es auf meinem Unraid-Homeserver düster aus: 1,7 MB/s vom Desktop zum Server, rund 90 Dateien pro Minute, und vom Projektordner waren gerade einmal 6.149 von 223.234 Dateien angekommen. Dabei hängt der Desktop mit 2,5 GBit/s und der Server mit 10 GBit/s am Netz, und die Verbindung lief direkt im LAN.

Zwei Änderungen am Container haben das auf 189 MB/s und rund 4.000 Dateien pro Minute gebracht – Faktor 110. Hier zeige ich, woran es lag, was ich geändert habe und welches Risiko eine der beiden Änderungen hat. Die Grundeinrichtung beschreibt Teil 1: Syncthing einrichten.

Das Wichtigste in Kürze

• Symptom: Große Dateien kamen flott an, Ordner mit Hunderttausenden kleinen Dateien krochen mit 1,7 MB/s.
• Ursache 1: Der Container schrieb über /mnt/user. Dort läuft jeder Zugriff durch shfs, das FUSE-Dateisystem von Unraid.
• Ursache 2: Syncthing ruft pro Datei fsync auf – auf einem Pool aus vier Festplatten heißt das jedes Mal Warten auf die Schreibköpfe.
• Lösung: Direkte Pool-Pfade statt /mnt/user und „Disable Fsync“ pro Ordner.
• Ergebnis: 189 statt 1,7 MB/s, rund 4.000 statt 90 Dateien pro Minute, null Fehler.
• Risiko: Ohne fsync kann ein Stromausfall einzelne Dateien unvollständig lassen – auf einem versionierten Sync-Ziel vertretbar, für die einzige Kopie nicht.

Die Symptome

Gemessen habe ich rund zwei Stunden nach dem Start:

Auffällig: Die Ordner mit großen Dateien – der Obsidian-Vault mit 16,5 GB und der Schreibtisch mit 7,5 GB – waren da längst fertig. Es hing ausschließlich an den vielen kleinen Dateien im Projektordner: Git-Objekte und Quellcode mit wenigen Kilobyte pro Datei.

Die Ursache: FUSE und fsync bei jeder Datei

shfs unter /mnt/user: Unraid setzt seine Shares aus dem Array und den Pools zu einem gemeinsamen Verzeichnisbaum unter /mnt/user zusammen. Das erledigt shfs, ein FUSE-Dateisystem im Userspace. Jeder Dateizugriff kostet dabei einen zusätzlichen Kontextwechsel durch diese Schicht. Bei einer großen Datei fällt das kaum auf, bei 250.000 kleinen Dateien summiert es sich.

fsync pro Datei: Syncthing schreibt jede Datei zuerst als temporäre Datei, ruft standardmäßig fsync auf, damit sie wirklich auf dem Datenträger steht, und benennt sie dann um. Auf meinem Pool aus vier 10-TB-Festplatten bedeutet jedes fsync Warten auf die Mechanik.

Zusammen ergibt das pro Datei mehrere Umläufe durch FUSE plus einen synchronen Schreibvorgang auf Festplatte. Die hohe CPU-Last des Containers war deshalb keine echte Rechenarbeit, sondern Warten auf Ein- und Ausgabe und Hash-Prüfung. Das Netz war nie der Engpass.

Lösung 1: Den Container an shfs vorbeiführen

Ich habe den Container mit direkten Pool-Pfaden neu angelegt. Physisch ist es derselbe Speicherort, denn der Share liegt ohnehin komplett auf dem Pool btrfs_data – nur der Umweg über FUSE fällt weg:

Die Konfiguration samt Index liegt damit auf dem NVMe-Cache, die Daten direkt auf dem Festplatten-Pool. Damit der Container in der Docker-Übersicht von Unraid bleibt, habe ich die Vorlage my-syncthing.xml entsprechend angepasst, statt ihn nur von Hand zu starten.

Das gilt nicht nur für Syncthing: Alle Container, die viele kleine Dateien schreiben – Datenbanken, Nextcloud, Git-Server – laufen auf Unraid mit direktem Pool- oder Cache-Pfad deutlich besser. Wie Unraid aufgebaut ist, erkläre ich in Unraid einrichten.

Alternative ab Unraid 6.12: Unraid kennt „exklusive Shares“. Liegt ein Share vollständig auf einem einzigen Pool und hat keinen zweiten Speicherort, liefert /mnt/user dafür einen direkten Verweis auf den Pool, und die Zugriffe laufen an FUSE vorbei. Dazu muss unter Settings → Global Share Settings die Option „Permit exclusive shares“ aktiv sein. Dann bringt auch der normale /mnt/user-Pfad die volle Leistung.

Vorsicht: Mische die Pfade nicht beim Kopieren. Dateien von einem direkten Pfad nach /mnt/user oder umgekehrt zu kopieren, obwohl es physisch dieselben Dateien sind, kann sie zerstören. Für einen Container legst du dich auf einen Pfad fest.

Lösung 2: fsync pro Datei abschalten

Die zweite Bremse habe ich pro Ordner gelöst: Die Option „Disable Fsync“ verzichtet auf das Erzwingen jedes einzelnen Schreibvorgangs. BTRFS bündelt die Schreibvorgänge dann selbst. In der Oberfläche findest du die Option unter Aktionen → Erweitert → Ordner → [Ordnername]:

Für neun Ordner geht es schneller über die REST-API:

curl -X PATCH -H "X-API-Key: $KEY" -H 'Content-Type: application/json' \
  -d '{"disableFsync":true}' http://127.0.0.1:8384/rest/config/folders/projekte

Abgeschaltet habe ich fsync nur auf dem Homeserver, also auf dem Sync-Ziel mit Versionierung. Desktop und Notebooks behalten die Voreinstellung.

Das Ergebnis

30 Sekunden nach dem Neustart des Containers:

Der Neustart unterbrach die Verbindung für etwa 15 Sekunden. Direkt danach erschienen kurz Warnungen „no connected device has the required version of this file“. Sie verschwanden, sobald die Geräte ihre Indizes neu ausgetauscht hatten, und der Abgleich setzte dort fort, wo er stand. Am Ende waren alle neun Ordner fertig: der Projektordner mit 250.378 Dateien und 169,2 GB vollständig, insgesamt 171,7 GB über die eine LAN-Verbindung übertragen, null Dateien ausstehend.

Wie riskant ist „Disable Fsync“?

Fällt beim Homeserver mitten im Abgleich der Strom aus, können einzelne gerade geschriebene Dateien unvollständig sein. Syncthing erkennt das beim nächsten Scan am Block-Hash und holt die Dateien neu vom Desktop. Für ein Sync-Ziel mit Versionierung, dessen Daten noch auf einem anderen Gerät liegen, ist das vertretbar. Für die einzige Kopie wichtiger Daten nicht.

Wer fsync abschaltet, hängt den Homeserver am besten zusätzlich an eine unterbrechungsfreie Stromversorgung (USV). Die überbrückt kurze Ausfälle und fährt den Server bei längeren sauber herunter.

Der Link zur USV ist ein Affiliate-Link zu Amazon. Kaufst du darüber, erhalte ich eine kleine Provision – der Preis ändert sich für dich nicht.

Checkliste: Syncthing schnell auf Unraid

• Daten-Volume direkt auf den Pool legen (/mnt/<pool>/…), nicht auf /mnt/user – oder exklusive Shares erlauben.
• Konfiguration und Index auf den NVMe-Cache (/mnt/cache/appdata/syncthing).
• Auf HDD-Pools „Disable Fsync“ für die Ordner auf dem versionierten Sync-Ziel setzen.
• Die Vorlage anpassen, damit der Container in der Docker-Übersicht bleibt.
• Die Ignore-Liste vor dem ersten Scan anlegen – jede ignorierte Datei ist eine Datei weniger durch den Flaschenhals.
• Nicht vom Netz täuschen lassen: Hohe CPU-Last bei wenig Durchsatz deutet auf Ein- und Ausgabe, nicht auf Rechenarbeit.

Fazit

Der Engpass lag nicht an Syncthing und nicht am Netz, sondern an zwei Eigenheiten des Speichers: dem FUSE-Umweg von Unraid und dem synchronen Schreiben jeder einzelnen Datei auf Festplatten. Beides zusammen kostete bei kleinen Dateien Faktor 110. Wer auf Unraid Syncthing oder einen anderen Container mit vielen kleinen Dateien betreibt, sollte die Pfade als Erstes prüfen.

Mehr zur Serie: Teil 1: Syncthing einrichten und Teil 3: Syncthing vs. Resilio Sync.

FAQ

Warum ist /mnt/user auf Unraid langsamer als der direkte Pfad?

Weil unter /mnt/user das FUSE-Dateisystem shfs die Shares aus Array und Pools zusammensetzt. Jeder Zugriff geht durch diese Schicht. Bei vielen kleinen Dateien summiert sich das, bei großen fällt es kaum auf.

Ist „Disable Fsync“ in Syncthing gefährlich?

Bei einem Stromausfall können einzelne gerade geschriebene Dateien unvollständig sein. Syncthing erkennt das beim nächsten Scan und holt sie neu. Auf einem Sync-Ziel mit Versionierung ist das vertretbar, für die einzige Kopie nicht.

Muss ich „Disable Fsync“ für jeden Ordner einzeln setzen?

Ja, die Option gilt pro Ordner. Für neue Ordner kannst du sie unter Aktionen → Erweitert → Vorgaben → Vorgabeordner voreinstellen.

Hilft das auch für Nextcloud oder Datenbanken auf Unraid?

Der direkte Pool-Pfad ja – jede Anwendung mit vielen kleinen Zugriffen profitiert davon. Die fsync-Option ist dagegen eine Syncthing-Einstellung; bei Datenbanken solltest du fsync nicht abschalten.

Betrifft das Problem auch Synology oder TrueNAS?

Den FUSE-Umweg von Unraid gibt es dort nicht. Das fsync-Thema kann aber jeden Festplatten-Pool treffen, auf den Syncthing sehr viele kleine Dateien schreibt.

Quellen

• Syncthing: Konfigurationsoptionen (disableFsync)
• Syncthing: REST-API
• Unraid 6.12: exklusive Shares
• Unraid-Forum: Docker-Container von /mnt/user/appdata auf /mnt/cache/appdata