NFS-Export scheint beschreibbar, Änderungen erscheinen aber nicht auf Festplatte

[joulethief]

Grüße allerseits, ich benötige eure Hilfe bei einem Problem, welches ich nicht so recht nachvollziehen kann:

Ich betreibe einen privaten Server mit Proxmox Virtual Environment 9.4.1.
Auf diesem laufen neben anderen:

• eine virtuelle Maschine für den Medien-Server Jellyfin und
• eine weitere VM für einen NFS-Server, um Medien von Clients aus hinzufügen zu können.

Alle Mediendateien für Jellyfin befinden sich auf einer einzelnen, XFS-formatierten Festplatte.
Der Ordner, unter dem diese Festplatte in Proxmox gemountet ist, wird als virtiofs-Share in die Jellyfin-VM gereicht.
Die VM des NFS-Servers erhält "rohen" Zugriff auf diese Festplatte über ein virtuelles Interface scsi1.

Was funktioniert:

• Jellyfin kann die Mediendaten lesen und abspielen.
• Der NFS-Server kann den konfigurierten Teil des Dateisystems für die angegebenen Clients exportieren.
• Die Clients können die NFS-Exports mounten und auf ihnen schreiben.

Das Problem:

• Die Dateimanager auf den Clients und das Dateisystem des NFS-Servers zeigen die vorgenommenen Dateiänderungen zwar an, aber
• diese werden offenbar nicht physisch auf die Festplatte geschrieben – das gleiche Verzeichnis bleibt aus Sicht des Proxmox-Hosts unverändert.

Hier noch einmal zur Veranschaulichung:

1. Der ursprüngliche Inhalt eines Film-Ordners aus Sicht der Jellyfin-VM...
   

   root@jellyfin:~# ls /mnt/Medien/Filme/Beispielfilm/
   Beispielfilm.mkv   Bonusmaterial

   
   ...und aus Sicht der NFS-Server-VM
   

   root@nfs-server:~# ls /srv/nfsv4/Medien/Filme/Beispielfilm/
   Beispielfilm.mkv   Bonusmaterial

   
   
2. Von einem NFS-Client aus sortiere ich die Dateien des Ordners "Bonusmaterial" um, damit diese von Jellyfin korrekt erkannt werden können. Das Dateisystem des NFS-Servers zeigt diese Änderungen:
   

   root@nfs-server:~# ls /srv/nfsv4/Medien/Filme/Beispielfilm/
   Beispielfilm.mkv   'Behind the Scenes'   Extras   Trailers

   
   
3. Die Inhalte eben dieses Ordners bleiben unverändert aus Sicht des Hosts und damit auch der Jellyfin-VM:
   

   root@proxmox:~# ls /mnt/Medien/Filme/Beispielfilm/
   Beispielfilm.mkv Bonusmaterial

   root@jellyfin:~# ls /mnt/Medien/Filme/Beispielfilm/
   Beispielfilm.mkv Bonusmaterial

Was mache ich falsch?


Edit: Hier noch die Konfigurationsdatei /etc/exports des NFS-Servers:

/srv/nfsv4              <IP_CLIENT_A>(rw,sync,root_squash,subtree_check,fsid=0)      <IP_CLIENT_B>(rw,sync,root_squash,subtree_check,fsid=0)
/srv/nfsv4/Medien       <IP_CLIENT_A>(rw,sync,root_squash,subtree_check)             <IP_CLIENT_B>(rw,sync,root_squash,subtree_check)

 

[Bu66as]

Hallo @joulethief,

Das Problem ist, dass du dasselbe XFS-Dateisystem gleichzeitig von zwei unabhängigen Systemen aus mountest – einmal vom Proxmox-Host (und per virtiofs an Jellyfin weitergereicht) und einmal von der NFS-Server-VM über das rohe SCSI-Device. Das ist mit einem nicht-clusterfähigen Dateisystem wie XFS nicht zulässig.

Jedes System hat seinen eigenen Buffer-Cache und sein eigenes Journal. Wenn die NFS-Server-VM schreibt, bekommt der Kernel des Hosts davon nichts mit – er arbeitet mit seinem veralteten Cache weiter. Umgekehrt genauso. Schlimmer noch: Das kann früher oder später zu Dateisystem-Korruption führen.

Lösung: Die Platte darf nur von einem System gemountet werden. Zwei sinnvolle Varianten:

1. NFS-Server-VM als alleinigen Zugriffspunkt nutzen: Die Platte nur der NFS-VM per SCSI zuweisen. Jellyfin greift dann ebenfalls per NFS auf die Medien zu statt per virtiofs. Den Mount auf dem Proxmox-Host entfernen.
2. NFS direkt auf dem Proxmox-Host betreiben: Die Platte bleibt auf dem Host gemountet, den NFS-Export machst du direkt vom Host aus (oder aus einem LXC-Container mit Bind-Mount). Die separate NFS-Server-VM entfällt. Jellyfin bekommt die Daten weiterhin per virtiofs.

Variante 2 wäre die einfachere Architektur – eine VM weniger, kein Raw-Device-Passthrough nötig. In jedem Fall: das Doppel-Mount zeitnah auflösen, bevor das XFS beschädigt wird.

 

[joulethief]

Danke für deine Hilfe.

Ich habe mich für Variante 1 entschieden, da ich im Zusammenhang mit NFS in LXC-Containern immer wieder auf Bedenken zur Sicherheit stoße (etwa dass der Container zwingend privilegiert sein muss), die Einrichtung kompliziert zu sein scheint oder sogar gar nicht offiziell unterstützt wird (Antwort von 2020, nicht sicher wie das zu bewerten ist). Das VM-Setup dagegen hat mich nicht viel Zeit gekostet.

Im ersten Moment schien alles wie gewünscht zu funktionieren, ein paar Minuten später hat dann genau das zugeschlagen, wovor du gewarnt hast. Mein Dateisystem war plötzlich nicht mehr verwendbar und musste mithilfe von xfs_repair -L repariert werden. Ein paar Dateien habe ich verloren, viele konnte ich aus lost+found wiederherstellen, alles in allem aber zum Glück keine schwerwiegenden Verluste.

Kannst du mir vielleicht noch sagen wonach ich suchen muss wenn ich genauer verstehen will, wie es dazu kam?

 

[Bu66as]

Das Stichwort ist Buffer-Cache-Kohärenz (bzw. englisch "cache coherency").

Kurz zusammengefasst: Jeder Linux-Kernel hält Dateisystem-Metadaten (Inodes, Verzeichniseinträge, Allokationstabellen) und Dateiinhalte im RAM als Page Cache vor. Ein lokales Dateisystem wie XFS geht davon aus, dass es den alleinigen Zugriff auf das Blockdevice hat – es gibt keinen Mechanismus, der einen zweiten Kernel über Änderungen informiert.

Wenn jetzt zwei Kernel gleichzeitig schreiben, passiert z.B. Folgendes:

• Kernel A alloziert Block 1000 für eine neue Datei und schreibt das in seinen Cache.
• Kernel B weiß nichts davon, hält Block 1000 für frei und überschreibt ihn.
• Kernel A schreibt seine Metadaten auf die Platte – die verweisen auf Block 1000, der jetzt aber andere Daten enthält.

Das Journal schützt hier nicht, weil jeder Kernel sein eigenes Journal führt. Beim Recovery spielt jeder Kernel nur sein eigenes Journal ab und macht dabei die Änderungen des anderen unter Umständen rückgängig.

Zum Weiterlesen eignen sich diese Suchbegriffe:

• dual mount filesystem corruption
• page cache coherency shared storage
• why you cannot mount a filesystem twice

Clusterfähige Dateisysteme wie GFS2 oder OCFS2 lösen genau dieses Problem über einen Distributed Lock Manager (DLM), der die Caches aller Knoten synchronisiert – für ein Heimsetup aber deutlich überdimensioniert.