Hat jemand Erfahrung mit der Verwendung des OpenStack Swift-Objektspeichers mit S3FS und mehreren Schreib-Mounts, die gleichzeitig auf dieselbe(n) Datei(en) zugreifen?
Die Manpage für s3 lautet beispielsweise:https://linux.die.net/man/1/s3fshat diesen Absatz:
„Multi-User-Fähigkeit: Obwohl es möglich ist, S3-Buckets für mehrere Benutzer freizugeben, verhindert das aktuelle Datenkonsistenzmodell für den S3-Dienst von Amazon die sichere Nutzung mehrerer Mounts durch mehrere Benutzer. Obwohl S3FS derzeit mehrere Mounts zulässt, können bei einer solchen Aktivität Daten beschädigt werden. Eine zukünftige Version wird einen Sperrmechanismus enthalten, der sicher vor mehreren Lese-/Schreib-Mounts schützt. Mehrere schreibgeschützte Mounts nach einem einzigen Lese-/Schreib-Mount sind sicher, spiegeln aber keine Änderungen wider, die durch den beschreibbaren Mount an den Datei- oder Dateisystemmetadaten vorgenommen wurden, was seine Nützlichkeit dort einschränkt.“
Ist der oben erwähnte Sperrmechanismus schon implementiert?
Danke, Mark
Antwort1
Diese Manpage bezieht sich auf ein anderes Python-basiertes s3fs, das um 2016 aus dem Internet verschwand und dessen Entwicklung 2009 eingestellt wurde:
https://web.archive.org/web/20161008081920/https://fedorahosted.org/s3fs/
Ich empfehle die Verwendung der populärerens3fs-Sicherungstattdessen. Ich habe dem Webmaster von die.net eine E-Mail geschickt, er solle versuchen, dies zu aktualisieren, da die Leute normalerweise auf die s3fs-fuse verweisen.
Insbesondere verfügt s3fs bei mehreren Schreibern nicht über POSIX-Semantik, was sich als Datenbeschädigung äußern kann. Der zugrunde liegende S3-Objektspeicher folgt einem Last-Writer-Wins-Modell, bei dem Objekte durch jeden PutObject- oder CompleteMultipartUpload-RPC atomar ersetzt werden. s3fs verfügt außerdem über ein Caching-Modell, das der Anwendung veraltete Daten bereitstellen kann.
yas3fsist ähnlich wie s3fs-fuse und implementiert Sperren über Amazon SNS/SQS. Dies führt Sie jedoch weiter außerhalb des OpenStack-Ökosystems.