mount fuse-filesystem Fehler bei Dateizugriff

[scientific]

Hi Leute!

Ich habe ein Fuse-Dateisystem für den Zugriff auf meine Backuppartitionen und Platten geschrieben, damit ich die Snapshots von allen Locations an einem Ort vereint habe.

Mounte ich das Ding mittels

Code: Alles auswählen

/etc/systemd/system/scripts/MksnapshotFS.py -ouroot=True /backup

kann ich unter /backup auf die Snapshots zugreifen, Dateien lesen und öffnen (ist alles readonly!!)
Mounte ich das mit

Code: Alles auswählen

mount /backup /etc/systemd/system/scripts/MksnapshotFS.py -tfuse -ouroot=True 

funktioniert auch der Dateizugriff in den Snapshots.

Jedoch mit der Unit:

Code: Alles auswählen

 /etc/systemd/system: # cat backup.mount
[Unit]
Before=local-fs.target

[Mount]
What=/etc/systemd/system/scripts/MksnapshotFS.py
Where=/backup
Type=fuse
TimeoutSec=10s
Options=uroot=True

klappt zwar das Listing in Verzeichnissen, jedoch werden Dateien beim Öffnen mit vim nicht geöffnet, vim zeigt die Datei an oder verweigert mit [Keine Erlaubnis]. cat meint, die Textdatei wäre ein Verzeichnis.
Das Spiel kann ich mit veränderten Mountoptionen (hinzufügen von ro und nofail, einzeln oder gemeinsam) spielen. Manchmal macht es die Datei auf, manchmal ist ein cat möglich, dann verweigert fuse das ganze wieder.

Aber so wie ich beobachten konnte, tritt das nur beim Mounten mit systemd auf. Aber das ganze Verhalten erinnert mich sehr an ein Würfelspiel.
Und wie ich hier diesen Text schreiben, fällt mir auf, die Zugriffe variieren auch ohne systemd. Mal krieg ich die Erlaubnis, mal nicht, mal wird ein textfile als solches Erkannt, mal als Verzeichnis... Eine Regel dahinter scheint es nicht zu geben.

Muss ich im Fuse-Dateisystem (hab es in python programmiert) irgendwelche Timeouts oder Wartezeiten berücksichtigen?
Die Vorlagen, anhand deren ich dieses Dateisystem entwickelt habe, hatten das alles nicht.

Ich charakterisiere kurz das Dateisystem:
Ich hab ein Verzeichnis /var/cache/btrfs_pool_SYSTEM/ in dem ich die Wurzel meines btrfs-Dateisystems gemountet habe. Darin sind alle Snapshots des Dateisystems.
Das Schema ist:

Code: Alles auswählen

# ls /var/cache/btrfs_pool_SYSTEM/|head -n5
__ALWAYSCURRENT__
__ALWAYSCURRENT__.2016-08-22_20:00:44.weekly
__ALWAYSCURRENT__.2016-08-24_00:40:44.manualy
__ALWAYSCURRENT__.2016-09-06_11:12:05.monthly
__ALWAYSCURRENT__.2016-10-06_22:56:15.initial

Unter __ALWAYSCURRENT__ ist dann /home/ und darunter die Userverzeichnisse /user1, /user2...

Das selbe Spiel ist auf /var/cache/backup/hostname/
Auch hier die __ALWAYSCURRENT__.*/home/user*... aber von der externen Platte, wohin die Snapshots gesendet werden.

auf /backup werden nun alle diese Snapshots abgebildet sowohl von /var/cache/btrfs_pool_SYSTEM als auch von /var/cache/backup/hostname
Ich schreibe die Namen nach Datum um ("heute" und "gestern" ersetzen das jeweilige Datum. Ältere Snapshots behalten den originalen Dateinamen) und die bekommen noch eine Endung "--loc" bzw. "--ext" für lokale Kopien oder jene auf der externen HD.

Als User kann man dieses Dateisystem ebenfalls nutzen (ohne Option uroot) und auf ~/backup z.b. mounten, dann sind aus den Snapshots nur die User-Verzeichnisse des Loginusers sichtbar und direkt ansteuerbar. Das Dateisystem blendet dann eine oder mehrere Verzeichnisebenen aus und mapped ebenfalls die Snapshot-Namen von "heute" und "gestern" auf Namen wie z.B. "heute_14-56-13--loc/"
Hier klappt der Zugriff bis jetzt problemfrei.

Falls jemand den Source des Filesystems ansehen möchte, ob dort der Hund begraben liegt:
https://github.com/xundeenergie/mksnaps ... pshotFS.py

lg scientific

[scientific]

Ich habs gefunden.
Und ausgebessert. Die completion der bash hat einen Bug in meinem Filesystem zum Vorschein gebracht.

Jetzt funktioniert es vollumfänglich und kann von meinem Github-Repo geladen werden.

Lg scientific