Cloud Storage FUSE

Einschränkungen und Unterschiede zu POSIX-Dateisystemen

In der folgenden Liste werden die Einschränkungen von Cloud Storage FUSE beschrieben:

• Metadaten: Cloud Storage FUSE überträgt beim Hochladen von Dateien in Cloud Storage keine Objektmetadaten, mit Ausnahme von mtime- und symlink-Zielen. Das bedeutet, dass Sie keine Objektmetadaten festlegen können, wenn Sie Dateien mit Cloud Storage FUSE hochladen. Wenn Sie Objektmetadaten beibehalten möchten, können Sie Dateien mit der Google Cloud CLI, der JSON API oder der Google Cloud Console hochladen.
• Nebenläufigkeit: Cloud Storage FUSE bietet keine Nebenläufigkeitserkennung für mehrere Schreibvorgänge in derselben Datei. Wenn mehrere Schreibvorgänge versuchen, eine Datei zu ersetzen, wird der letzte Schreibvorgang ausgeführt und alle vorherigen gehen verloren. Es gibt keine Zusammenführung, keine Versionsverwaltung und keine Nutzerbenachrichtigungen bei späterem Überschreiben.
• Verknüpfen: Cloud Storage FUSE unterstützt keine harten Links.
• Dateisperren und Dateipatching: Cloud Storage FUSE unterstützt weder das Sperren von Dateien noch das Patchen von Dateien. Daher sollten Sie keine Repositories zur Versionsverwaltung in Cloud Storage FUSE-Bereitstellungspunkten speichern, da Versionsverwaltungssysteme auf Dateisperren und Patches angewiesen sind. Darüber hinaus sollten Sie Cloud Storage FUSE nicht als Filer-Ersatz verwenden.
• Semantik: Die Semantik in Cloud Storage FUSE unterscheidet sich von der Semantik in einem herkömmlichen Dateisystem. Metadaten wie zum Beispiel die Zeit des letzten Zugriffs werden nicht unterstützt und einige Metadatenvorgänge wie das Umbenennen von Verzeichnissen sind nicht unteilbar. Eine Liste der Unterschiede zwischen der Cloud Storage FUSE-Semantik und der herkömmlichen Dateisystemsemantik finden Sie unter Semantik in der GitHub-Dokumentation zu Cloud Storage FUSE.
• Arbeitslasten, die Datei-Patching durchführen (oder direkt überschreiben): Cloud Storage FUSE kann nur ganze Objekte gleichzeitig in Cloud Storage schreiben und bietet keinen Mechanismus zum Patchen. Wenn Sie versuchen, eine Datei zu patchen, lädt Cloud Storage FUSE die gesamte Datei noch einmal hoch. Die einzige Ausnahme besteht darin, dass Sie Inhalte an das Ende einer Datei anhängen können, die mindestens 2 MB groß ist. Dann lädt Cloud Storage FUSE nur den angehängten Inhalt noch einmal hoch.
• Zugriff: Die Autorisierung für Dateien wird über die Cloud Storage-Berechtigungen gesteuert. Die Zugriffssteuerung im POSIX-Stil ist nicht möglich.
• Leistung: Cloud Storage FUSE hat eine erheblich höhere Latenz als ein lokales Dateisystem und sollte daher nicht als Backend zum Speichern einer Datenbank verwendet werden. Der Durchsatz kann verringert sein, wenn Sie kleine Dateien einzeln lesen oder schreiben. Wenn Sie größere Dateien und/oder mehrere Dateien gleichzeitig übertragen, erhöhen Sie den Durchsatz.
• Verfügbarkeit: Wenn Sie Cloud Storage FUSE für den Zugriff auf Cloud Storage verwenden, können vorübergehende Fehler auftreten. Es wird empfohlen, fehlgeschlagene Vorgänge mithilfe von Wiederholungsstrategien zu wiederholen.
• Objektversionsverwaltung: Cloud Storage FUSE unterstützt derzeit nicht die Verwendung mit Buckets, für die die Objektversionsverwaltung aktiviert ist. Der Versuch, Cloud Storage FUSE mit Buckets zu verwenden, für die die Objektversionsverwaltung aktiviert ist, kann zu unerwarteten Ergebnissen führen.
• Dateitranscodierung: Objekte mit content-encoding: gzip in Metadaten: Bei solchen Objekten in einem von Cloud Storage FUSE bereitgestellten Verzeichnis wird keine dekomprimierende Transcodierung durchgeführt. Stattdessen bleibt das Objekt auf dieselbe Weise komprimiert, wie es im Bucket gespeichert ist.
  Beispielsweise kann eine Datei mit 1.000 Byte, die mit dem Befehl gcloud storage cp und dem Flag --gzip-local in einen Bucket hochgeladen wurde, mit 60 Byte (die tatsächliche komprimierte Größe hängt vom Inhalt und der von der gcloud CLI verwendeten gzip-Implementierung ab) zum Cloud Storage-Objekt werden. Wenn der Bucket mit gcsfuse bereitgestellt wird und die entsprechende Datei aufgelistet oder aus dem Bereitstellungsverzeichnis gelesen wird, wird seine Größe als 60 Byte zurückgegeben und der Inhalt ist eine komprimierte Version der ursprünglichen 1.000 Byte. .
  Dies unterscheidet sich von einem Download mit gcloud storage cp gs://bucket/path /local/path, der einer dekomprimierenden Transcodierung unterzogen wird: Im Befehl gcloud werden die Inhalte während des Downloads automatisch dekomprimiert und die unkomprimierte Originalinhalte werden bereitgestellt.
  Hinweis: Der Versuch, Cloud Storage FUSE zum Bearbeiten oder Ändern von Objekten mit content-encoding: gzip zu verwenden, kann zu unerwarteten Ergebnissen führen. Dies liegt daran, dass Cloud Storage FUSE den Objektinhalt unverändert (ohne Komprimierung) und unter Beibehaltung von content-encoding: gzip hochlädt. Wenn dieser Inhalt nicht ordnungsgemäß mit GZIP komprimiert ist, kann er vom Server nicht von anderen Clients wie die gcloud CLI gelesen werden. Dies liegt daran, dass andere Clients beim Lesen eine dekomprimierende Transcodierung nutzen und bei fehlerhaften gzip-Inhalten ein Fehler auftritt.
• Aufbewahrungsrichtlinien: Cloud Storage FUSE unterstützt nicht das Schreiben in Buckets mit einer Aufbewahrungsrichtlinie. Wenn Sie versuchen, in einen Bucket mit einer Aufbewahrungsrichtlinie zu schreiben, schlagen die Schreibvorgänge fehl.

  Cloud Storage FUSE unterstützt das Lesen von Objekten aus Buckets mit einer Aufbewahrungsrichtlinie. Der Bucket muss jedoch als Read-Only bereitgestellt sein, da das -o RO-Flag während der Bucket-Bereitstellung übergeben wird.

• Lokaler Speicher: Neue oder geänderte Objekte werden komplett in einer lokalen temporären Datei gespeichert, bis sie geschlossen oder synchronisiert werden. Achten Sie beim Verwenden großer Dateien darauf, dass Sie genügend lokale Speicherkapazität für temporäre Kopien der Dateien haben, vor allem wenn Sie mit Compute Engine-Instanzen arbeiten. Weitere Informationen finden Sie in der README-Datei in der GitHub-Dokumentation zu Cloud Storage FUSE.
• Verzeichnisse: Cloud Storage arbeitet mit einem flachen Namespace. Standardmäßig können im bereitgestellten Dateisystem nur Verzeichnisse angezeigt werden, die explizit definiert (als Objekte in Cloud Storage vorhanden) sind. Implizite Verzeichnisse, also solche, die nur Teile des Pfads anderer Dateien oder Verzeichnisse sind, werden standardmäßig nicht angezeigt. Bei Dateien mit einem Pfad, der ein implizites Verzeichnis enthält, wird die Datei nicht im Gesamtverzeichnisbaum angezeigt, da das implizite Verzeichnis, in dem sie enthalten sind, nicht angezeigt wird. Sie können dieses Verhalten jedoch mit einem Flag ändern. Weitere Informationen finden Sie in der Dokumentation zur Cloud Storage FUSE CLI unter dem Flag --implicit-dirs.

  Cloud Storage FUSE unterstützt nicht das Umbenennen von Verzeichnissen. Das Umbenennen eines Verzeichnisses kann in Cloud Storage nicht atomar durchgeführt werden. Stattdessen wird beim Umbenennen eines Verzeichnisses ein Objekt mit einem neuen Namen kopiert und das ursprüngliche Objekt gelöscht.

• Dateihandle-Limits: Der Linux-Kernel lässt standardmäßig maximal 1.024 offene Dateihandles zu. Cloud Storage FUSE sollte nicht als Server verwendet werden, der gleichzeitige parallele Verbindungen von externen Clients verarbeitet, da dies möglicherweise die maximale Anzahl offener Dateihandles überschreitet. die folgenden gängigen Anwendungsfälle sollten vermeiden werden: Offenlegen von Inhalten aus einer Cloud Storage FUSE-Bereitstellung, Veröffentlichen einer Cloud Storage FUSE-Bereitstellung als NAS (Network Attached Storage) über Dateifreigabeprotokolle (z. B. NFS oder SMB) und Hosten eines FTP-Servers (File Transfer Protocol), der durch eine Cloud Storage FUSE-Bereitstellung gesichert ist.