Fehlerbehebung bei BlobFuse

In diesem Artikel werden häufig auftretende Probleme erläutert, die beim Verwenden von BlobFuse auftreten können.

Häufige Einbindungsprobleme

In diesem Abschnitt werden häufig auftretende Probleme aufgeführt, die auftreten können, wenn Sie versuchen, einen Container zu mounten.

Fehler: fusermount: Fehler beim Öffnen von /etc/fuse.conf: Berechtigung verweigert

Nur Benutzer, die Teil der fuse-Gruppe sind, und der Stammbenutzer können den fusermount Befehl ausführen. Um dieses Problem zu beheben, fügen Sie Ihr Benutzerkonto mithilfe des folgenden Befehls zur Fuse-Gruppe hinzu.

sudo addgroup <user> fuse

Fehler: Der Bereitstellungsbefehl wurde erfolgreich ausgeführt, aber das Protokoll zeigt "Fehler beim Initieren von FUSE" an.

Wenn Sie die allow-other: true Konfiguration verwenden, stellen Sie sicher, dass sie user_allow_other in der /etc/fuse.conf Datei aktiviert ist. /etc/fuse.conf Standardmäßig ist diese Option deaktiviert. Sie müssen sie aktivieren und die Datei speichern.

Fehler beim Bereitstellen: Fehler bei der Authentifizierung der Anmeldeinformationen für Azure Storage

Möglicherweise liegt ein Problem mit der Speicherkonfiguration vor. Überprüfen Sie den Namen des Speicherkontos, den Kontoschlüssel und den container/filesystem Namen.

Mögliche Ursachen für dieses Problem sind die folgenden Probleme:

• Ungültiges Konto oder Zugriffsschlüssel.

• Nicht vorhandener Container. Sie müssen den Container erstellen, bevor Sie BlobFuse einbinden.

• Windows-Zeilenende (CRLF). Führen Sie dos2unixaus, um dieses Problem zu beheben.

• Verwendung von HTTP, während "Secure Transfer (HTTPS)" auf einem Speicherkonto aktiviert ist.

• Aktivierte Sicherheitsregel für virtuelle Netzwerke, die verhindert, dass die VM eine Verbindung zum Speicherkonto herstellt. Stellen Sie sicher, dass Sie mithilfe von AzCopy oder Azure CLI eine Verbindung mit Ihrem Speicherkonto herstellen können.

• DNS-Probleme und Timeouts. Um die DNS-Suche zu umgehen, fügen Sie die Auflösung des Speicherkontos zu /etc/hosts.

• Wenn Sie einen Proxyendpunkt verwenden, stellen Sie sicher, dass Sie das richtige Übertragungsprotokoll HTTP im Vergleich zu HTTPS verwenden.

Für die Autorisierung verwalteter Dienstidentitäten (MSI) oder Dienstprinzipalen (SPN) wird in der Antwort der HTTP-Statuscode „403“ zurückgegeben. Autorisierungsfehler

• Überprüfen Sie die Zugriffsrollen ihres Speicherkontos. Stellen Sie sicher, dass Sie sowohl die Rollen Contributor als auch Storage Blob Contributor für die MSI- oder SPN-Identität haben.
• Stellen Sie für private AAD-Endpunkte (private MSI-Endpunkte) sicher, dass Ihre Umgebungsvariablen ordnungsgemäß konfiguriert sind.

fusermount: Einbindung fehlgeschlagen: Vorgang nicht erlaubt (CentOS)

Standardmäßig ist fusermount ein privilegierter Vorgang auf CentOS. Sie können dieses Problem umgehen, indem Sie die Berechtigungen des fusermount Vorgangs ändern.

chown root /usr/bin/fusermount
chmod u+s /usr/bin/fusermount

Auf das bereitgestellte Verzeichnis kann nicht zugegriffen werden

FUSE unterstützt die Montage von Dateisystemen im Benutzerbereich. Auf das bereitgestellte Dateisystem kann nur der Benutzer zugreifen, der es bereitgestellt hat. Wenn Sie z. B. ein Dateisystem mithilfe von root einbinden, aber versuchen, mithilfe eines anderen Benutzers darauf zuzugreifen, schlägt der Zugriff fehl. Um diese Einschränkung zu umgehen, verwenden Sie die nicht sichere Sicherungsoption --allow-other.

sudo blobfuse2 mount /home/myuser/mount_dir/ --config-file=config.yaml --allow-other

fusermount: Befehl nicht gefunden

Dieser Fehler kann auftreten, wenn Sie versuchen, die Einbindung des Blob Storage aufzuheben, der empfohlene Befehl jedoch nicht gefunden wird. Während umount möglicherweise stattdessen funktioniert, wird fusermount als die empfohlene Methode angesehen. Installieren Sie daher das fuse-Paket. Im folgenden Beispiel wird das FUSE-Paket auf Ubuntu 20+ installiert.

sudo apt install fuse3

Hängt beim Einbinden in ein Private Link-Speicherkonto

Die BlobFuse-Konfigurationsdatei sollte den Kontonamen als ursprünglichen Speicherkontonamen angeben, nicht den Namen des Speicherkontos für private Verknüpfungen. Beispiel: myblobstorageaccount.blob.core.windows.net ist richtig, während privatelink.myblobstorageaccount.blob.core.windows.net es falsch ist.

Wenn die Konfigurationsdatei korrekt ist, überprüfen Sie die Namensauflösung. Zum Beispiel sollte dig +short myblobstorageaccount.blob.core.windows.net eine private IP-Adresse wie 10.0.0.5 zurückgeben.

Wenn die Übersetzung und die Namensauflösung fehlschlagen, überprüfen Sie die Einstellungen des virtuellen Netzwerks, um sicherzustellen, dass DNS-Übersetzungsanforderungen an den von Azure bereitgestellten DNS 168.63.129.16weitergeleitet werden. Wenn die BLOBFuse-Hosting-VM für die Weiterleitung an einen benutzerdefinierten DNS-Server konfiguriert ist, überprüfen Sie die benutzerdefinierten DNS-Einstellungen, um sicherzustellen, dass sie DNS-Anforderungen an den von Azure bereitgestellten DNS 168.63.129.16weiterleiten.

Um DNS-Probleme bei der Integration eines privaten Endpunkts in Azure Private DNS zu beheben, überprüfen Sie, ob der private Endpunkt über den richtigen DNS-Eintrag in der privaten DNS-Zone verfügt. Wenn der private Endpunkt gelöscht und neu erstellt wurde, ist möglicherweise eine neue IP vorhanden oder doppelte Datensätze vorhanden, was dazu führen kann, dass Clients Roundrobin verwenden und die Konnektivität instabil machen. Sie können auch überprüfen, ob die DNS-Einstellungen der Azure-VM über die richtigen DNS-Server verfügen. DNS-Einstellungen können auf der Ebene des virtuellen Netzwerks und der NIC-Ebene definiert werden. Sie können KEINE DNS-Einstellungen innerhalb der VM-NIC des Gastbetriebssystems konfigurieren.

Stellen Sie bei benutzerdefinierten DNS-Servern sicher, dass die benutzerdefinierten DNS-Server alle Anforderungen an 168.63.129.16 weiterleiten. Wenn dies der Fall ist, sollten Sie azure Private DNS-Zonen ordnungsgemäß nutzen können. Andernfalls müssen Sie möglicherweise eine bedingte Weiterleitung entweder an die Private-Link-Zone oder an die ursprüngliche PaaS-Dienstzone erstellen.

Wenn ein benutzerdefiniertes DNS nur Root-Treffer aufweist, ist es am besten, einen Weiterleiter zu 168.63.129.16 zu konfigurieren, da dies die Leistung verbessert und keine zusätzliche Einstellung für die bedingte Weiterleitung erforderlich ist.

Wenn ein benutzerdefinierter DNS-Server über DNS-Weiterleitungen zu einem anderen DNS-Server verfügt (einem nicht von Azure bereitgestelltem DNS-Server), müssen Sie eine bedingte Weiterleitung zur ursprünglichen PaaS-Domänenzone erstellen (d. h., Sie sollten eine bedingte blob.core.windows.net-Weiterleitung zu 168.63.129.16 konfigurieren). Denken Sie daran, dass bei Verwendung dieses Ansatzes alle DNS-Anforderungen an das Speicherkonto, mit oder ohne einen privaten Endpunkt, von dem von Azure bereitgestellten DNS aufgelöst werden. Durch die Verwendung mehrerer benutzerdefinierter DNS-Server in Azure können Sie eine höhere Verfügbarkeit für Anforderungen erreichen, die aus der lokalen Umgebung kommen.

BlobFuse von OOM beendet

Der "OOM Killer" oder "Out of Memory Killer" ist ein Prozess, den der Linux-Kernel verwendet, wenn das System kritisch wenig Arbeitsspeicher hat. Basierend auf seinem Algorithmus tötet es einen oder mehrere Prozesse, um Speicherplatz freizugeben. BlobFuse kann ein solcher Prozess sein. Um zu untersuchen, ob BlobFuse vom OOM-Killer getötet wurde, führen Sie den folgenden Befehl aus:

dmesg -T | egrep -i 'killed process'

Wenn die BlobFuse-Prozess-ID (PID) in der Ausgabe angezeigt wird, sendet die OOM-Beendigung ein SIGKILL-Signal an BlobFuse. Wenn BlobFuse nicht als Dienst ausgeführt wird, wird es nicht automatisch neu gestartet, und Sie müssen es manuell erneut einhängen. Wenn diese Bedingung weiterhin auftritt, überwachen Sie das System, und untersuchen Sie, warum das System wenig Arbeitsspeicher hat. Möglicherweise müssen Sie den virtuellen Computer aktualisieren, wenn eine solche hohe Speicherauslastung erwartet wird.

Zugriff auf HNS-aktiviertes Speicherkonto hinter einem privaten Endpunkt nicht möglich

Fügen Sie type: adls für HNS-fähige Konten immer unter dem azstorage Abschnitt in Ihrer Konfigurationsdatei hinzu. Vermeiden Sie die Verwendung von endpoint, es sei denn, Ihr Speicherkonto befindet sich hinter einem privaten Endpunkt. BlobFuse verwendet blob- und DFS-Endpunkte, um eine Verbindung mit dem Speicherkonto herzustellen. Sie müssen beide Endpunkte über dem privaten Endpunkt verfügbar machen, damit BlobFuse ordnungsgemäß funktioniert.

So erstellen Sie einen privaten Endpunkt für DFS im Azure-Portal: Wechseln Sie zu Ihrem Speicherkonto –> Netzwerk –> Private Endpunktverbindungen. Wählen Sie + Private endpoint"Abonnement", "Ressourcengruppe", "Name", "Netzwerkschnittstellenname" und "Region" aus. Wählen Sie "Weiter" aus, und wählen Sie unter "Zielunterressource" die Option dfsaus. Wählen Sie virtuelles Netzwerk und dann virtuelles Netzwerk und Subnetz aus. Wählen Sie DNS aus. Wählen Sie "Ja" für die Integration mit privatem DNS aus. Wählen Sie die Abonnement- und Ressourcengruppe für Ihren privaten Link DNS aus. Wählen Sie „Weiter“, „Weiter“ und dann „Erstellen“ aus.

Fehler beim Initialisieren der neuen Pipeline [Konfigurationsfehler in Azstorage [Kontoname nicht angegeben]]

Stellen Sie sicher, dass die Konfigurationsdatei den Abschnitt azstorage enthält.

Die BlobFuse-Basiskonfigurationsdatei enthält eine Liste aller Einstellungen und eine kurze Erläuterung der einzelnen Einstellungen. Verwenden Sie die Konfigurationsdatei der Beispieldatei für den Dateicache oder die Beispieldatei für die Blockcachekonfiguration , um schnell zu beginnen, indem Sie einige grundlegende Einstellungen für jedes dieser Szenarien verwenden.

Fehler beim Einbinden in die Proxyeinrichtung [proxyconnect tcp: dial tcp: lookup : kein solcher Host]

Stellen Sie sicher, dass Sie die Proxy-URL in der Umgebungsvariable https_proxy oder http_proxy festlegen und dass sie für den BlobFuse-Prozess zugänglich ist. Wenn Sie den privaten Endpunkt verwenden, stellen Sie sicher, dass er auf den endpoint-Abschnitt im azstorage-Abschnitt der Konfiguration verweist. Alternativ können Sie eine DNS-Auflösung verwenden, bei der account.blob.core.windows.net wieder auf den privaten Endpunkt aufgelöst wird. Stellen Sie bei einem HNS-Konto sicher, dass der private Endpunkt sowohl für BLOB- als auch dfs-Konten konfiguriert ist.

BlobFuse stellt die HTTPS-Kommunikation mit blobfuse2.z13.web.core.windows.net her.

Beim Einhängen versucht BlobFuse zu überprüfen, ob ein Upgrade verfügbar ist. Sie stellt eine Verbindung zu blobfuse2.z13.web.core.windows.net her und ruft die neuesten Versionsdetails ab. Falls dieser Aufruf aufgrund einer Netzwerkrichtlinie oder einer Firewall fehlschlägt, wird der Mount-Vorgang fortgesetzt. Falls eine neue Version verfügbar ist, wird eine Meldung auf der Shell gedruckt, die ein Upgrade aufruft. Im Falle eines Fehlers wird nur eine Protokollnachricht ausgegeben, die für Dateisystemvorgänge oder das Einhängen harmlos ist. Wenn BlobFuse diese Überprüfung nicht durchführen soll, fügen Sie dem Mount-Befehl einen CLI-Parameter --disable-version-check=true hinzu.

Häufige Probleme nach einer erfolgreichen Einbindung

In diesem Abschnitt werden häufig auftretende Probleme aufgeführt, die nach der erfolgreichen Bereitstellung eines Containers auftreten können.

Errno 24: Fehler beim Öffnen der Datei /mnt/tmp/root/filex im Dateicache. errno = 24 ODER Fehler: Zu viele Dateien geöffnet

Errno 24 in Linux entspricht einem Fehler: "Zu viele Dateien geöffnet". Dieser Fehler tritt auf, wenn eine Anwendung mehr Dateien öffnet, als das System zulässt. BlobFuse erlaubt in der Regel 20 weniger Dateien als der ulimit-Wert, den Sie in Linux festlegen. Normalerweise beträgt der Linux-Grenzwert 1.024 pro Prozess. BlobFuse ermöglicht z. B. gleichzeitig 1.004 geöffnete Dateideskriptoren. Um dieses Problem zu beheben, bearbeiten Sie /etc/security/limits.conf in Ubuntu, und fügen Sie diese beiden Zeilen hinzu:

soft nofile 16384
hard nofile 16384

Der Wert 16384 bezieht sich auf die Anzahl der zulässigen geöffneten Dateien. Sie müssen nach dem Bearbeiten dieser Datei für BlobFuse neu starten, um die neuen Grenzwerte aufzunehmen. Sie können den Grenzwert erhöhen, indem Sie den Befehl ulimit -n 16834verwenden. Dieser Befehl funktioniert jedoch nicht in Ubuntu.

Eingabe-/Ausgabefehler

Wenn Sie einen BLOB-Container erfolgreich bereitgestellt haben, aber ein Verzeichnis nicht erstellen oder eine Datei hochladen konnten, besteht dies möglicherweise darin, dass Sie einen BLOB-Container aus einem Premium-Blob-Konto (Page) bereitgestellt haben, das "Blob blockieren" nicht unterstützt. BlobFuse verwendet Block Blobs als Dateien und erfordert Konten, die Block blobs unterstützen.

mkdir: cannot create directory ‘directoryname' : Input/output error

Unerklärlich hohe Nutzungskosten für Speicherkontenlisten

Der wahrscheinlichste Grund für hohe Nutzungskosten für Speicherkontenlisten ist das automatische Scannen, das von updatedb über den integrierten mlocate-Dienst ausgelöst wird, der mit Linux-VMs bereitgestellt wird. mlocate ist ein integrierter Dienst, der als Suchtool fungiert. Der Dienst wird unter /etc/cron.daily hinzugefügt, um täglich ausgeführt zu werden und löst den updatedb Dienst aus, um jedes Verzeichnis auf dem Server zu scannen. Der Dienst erstellt den Dateiindex in der Datenbank neu, um suchergebnisse up-to-date beizubehalten.

Um dieses Problem zu beheben, geben Sie den folgenden Befehl in die Shell-Eingabeaufforderung ein: ls -l /etc/cron.daily/mlocate. Wenn mlocate in /etc/cron.daily vorhanden ist, fügen Sie BlobFuse der Ausschlussliste hinzu, sodass das BlobFuse-Bereitstellungsverzeichnis nicht von updatedb durchsucht wird. Aktualisieren Sie die updatedb.conf-Datei.

1. Um diese Datei zu aktualisieren, geben Sie cat /etc/updatedb.conf.

   Der Inhalt ähnelt folgendem:

   PRUNE_BIND_MOUNTS="yes"
   
   PRUNENAMES=".git .bzr .hg .svn"
   
   PRUNEPATHS="/tmp /var/spool /media /var/lib/os-prober /var/lib/ceph /home/.ecryptfs /var/lib/schroot"
   
   PRUNEFS="NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs devtmpfs fuse.mfs shfs sysfs cifs lustre tmpfs usbfs udf fuse.glusterfs fuse.sshfs curlftpfs ceph fuse.ceph fuse.rozofs ecryptfs fusesmb"
   

2. Fügen Sie den BlobFuse-Bereitstellungspfad (z. B. /mnt) zum PRUNEPATHS hinzu.

3. Fügen Sie "Blobfuse2" und "fuse" zu PRUNEFS hinzu. Das Hinzufügen beider Werte verursacht keinen Schaden.

   Um diese Konfiguration beim Erstellen von Pods zu automatisieren, erstellen Sie ein neues configmap im Cluster, das die neue Konfiguration zum Skript enthält. Erstellen Sie dann einen DaemonSet mit dem neuen configmap , der die Konfigurationsänderungen auf jeden Knoten im Cluster anwenden kann.

   Example:
   configmap file: (testcm.yaml)
   apiVersion: v1
   kind: ConfigMap
   metadata:
   name: testcm
   data:
   updatedb.conf: |
   PRUNE_BIND_MOUNTS="yes"
   PRUNEPATHS="/tmp /var/spool /media /var/lib/os-prober /var/lib/ceph /home/.ecryptfs /var/lib/schroot /mnt /var/lib/kubelet"
   PRUNEFS="NFS nfs nfs4 rpc_pipefs afs binfmt_misc proc smbfs autofs iso9660 ncpfs coda devpts ftpfs devfs devtmpfs fuse.mfs shfs sysfs cifs lustre tmpfs usbfs udf fuse.glusterfs use.sshfs curlftpfs ceph fuse.ceph fuse.rozofs ecryptfs fusesmb fuse Blobfuse2"
   DaemonSet file: (testcmds.yaml)
   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
   name: testcmds
   labels:
   test: testcmds
   spec:
   selector:
   matchLabels:
   name: testcmds
   template:
   metadata:
   labels:
   name: testcmds
   spec:
   tolerations:
   - key: "kubernetes.azure.com/scalesetpriority"
   operator: "Equal"
   value: "spot"
   effect: "NoSchedule"
   containers:
   - name: mypod
   image: debian
   volumeMounts:
   - name: updatedbconf
   mountPath: "/tmp"
   - name: source
   mountPath: "/etc"
   command: ["/bin/bash","-c","cp /tmp/updatedb.conf /etc/updatedb.conf;while true; do sleep 30; done;"]
   restartPolicy: Always
   volumes:
   - name: updatedbconf
   configMap:
   name: testcm
   items:
   - key: "updatedb.conf"
   path: "updatedb.conf"
   - name: source
   hostPath:
   path: /etc
   type: Directory
   
   

Dateiinhalte werden nicht mit Speicher synchronisiert

Verweisen Sie auf die Einstellung timeout-sec der Dateicachekomponente.

Fehler beim Aufheben der Bereitstellung

Das Aufheben der Einbindung schlägt fehl, wenn eine Datei geöffnet ist oder wenn eine benutzende Person oder ein Prozess Verzeichnisse in das Einbindungsverzeichnis oder dessen Unterverzeichnisse ändert. Stellen Sie sicher, dass keine Dateien verwendet werden, und versuchen Sie es erneut mit dem Befehl "Unmount". Auch umount -f funktioniert nicht, wenn die eingehängten Dateien oder Verzeichnisse verwendet werden. umount -l führt eine Lazy-Aufhebung der Einbindung aus, d. h., sie wird automatisch aufgehoben, wenn die eingebundenen Dateien nicht mehr verwendet werden.

BlobFuse wird eingebunden, funktioniert jedoch überhaupt nicht

Antischadsoftware und Antivirensoftware können FUSE-Funktionen blockieren. In solchen Fällen funktioniert die FUSE-Funktion nicht, obwohl der Bereitstellungsbefehl erfolgreich ist und die BlobFuse-Binärdatei ausgeführt wird. Eine Möglichkeit, dieses Problem zu identifizieren, besteht darin, Debugprotokolle zu aktivieren und BlobFuse zu mounten. Wenn keine Protokolle von BlobFuse angezeigt werden, ist dieses Problem möglicherweise aufgetreten. Beenden Sie die Antivirensoftware, und versuchen Sie es erneut. In solchen Fällen funktioniert das Einhängen über /etc/fstab, da es den Einhängebefehl ausführt, bevor die Anti-Malware-Software gestartet wird.

Temporäres Verzeichnis des Dateicaches nicht leer

Um sicherzustellen, dass es keine Restdateien im temporären Verzeichnis Ihres Dateicaches gibt, sollten Sie die Einbindung von BlobFuse aufheben, statt BlobFuse zu beenden. Wenn Sie BlobFuse beenden, ohne die Einbindung aufzuheben, legen Sie für die nächste Einbindung cleanup-on-start in Ihrer Konfigurationsdatei fest, um das temporäre Verzeichnis zu löschen.

Vorhandene Datei kann nicht geändert werden (Fehler: ungültiges Argument)

Standardmäßig ist writeback-cache für libfuse3 aktiviert, und diese Einstellung kann dazu führen, dass Anfüge- und Schreibvorgänge fehlschlagen. Sie können den Schreibcache deaktivieren, wodurch die Leistung verringert werden kann, oder BlobFuse so konfigurieren, dass geöffnete Flags ignoriert werden, die der Benutzer bereitstellt, sodass er mit Writeback-Cache funktioniert.

Um den Writeback-Cache zu deaktivieren, fügen Sie disable-writeback-cache: true im Abschnitt "libfuse" Ihrer Konfigurationsdatei hinzu.

Fügen Sie ignore-open-flags: true unter dem Abschnitt "libfuse" in Ihrer Konfigurationsdatei hinzu, damit es mit "writeback-cache" funktioniert.

Dateien und Verzeichnisse für Flach-Namespace-Konten können nicht aufgeführt werden.

Bei Nicht-HNS-Konten erwartet BlobFuse, dass spezielle Verzeichnismarkierungsdateien im Container vorhanden sind, um ein Verzeichnis zu identifizieren. Wenn diese Dateien nicht vorhanden sind, setzen Sie virtual-directory: true im Abschnitt azstorage.

Dateigröße und LMT aktualisieren sich, aber die Dateiinhalte aktualisieren sich nicht.

BlobFuse unterstützt sowohl fuse2- als auch fuse3-kompatible Linux-Distributionen. In allen Linux-Verteilungen speichert der Kernel Dateiinhalte im Seitencache zwischen. Solange der Cache gültig ist, dient das System Lese- und Schreibvorgängen aus dem Cache. Aufrufe erreichen nicht die Dateisystemtreiber, was in diesem Fall BlobFuse ist. Das System macht diesen Seitencache ungültig, wenn die Seite ausgelagert wird, der Benutzer ihn manuell über die CLI löscht oder wenn der Dateisystemtreiber dies anfordert.

In fuse2-kompatiblen Verteilungen unterstützt libfuse das Ungültigieren des Seitencaches nicht. Inhalte, die einmal zwischengespeichert wurden, bleiben beim Kernel erhalten, bis der Benutzer den Seitencache manuell löscht oder der Kernel entscheidet, ihn auszutauschen. Dies bedeutet, dass auch wenn sich die Dateigröße oder lmT geändert hat und BlobFuse entscheidet, den Inhalt durch erneutes Herunterladen der Datei zu aktualisieren, erhält der Benutzer weiterhin veraltete Inhalte zum Lesen.

In fuse3-kompatiblen Verteilungen konfiguriert BlobFuse libfuse so, dass der Seitencache ungültig wird, wenn sich die Dateigröße oder LMT ändert, sodass dieses Problem nicht auftritt.

Wenn Sie feststellen, dass Listen- oder Stat-Aufrufe an eine Datei aktualisierte Uhrzeit oder Größe anzeigen, der Inhalt die Änderungen jedoch nicht widerspiegelt, bestätigen Sie zunächst mit BlobFuse-Protokollen, dass die Datei tatsächlich frisch heruntergeladen wurde. Wenn das Timeout für den Dateicache nicht abgelaufen ist, verwendet BlobFuse weiterhin die aktuelle Version der im temporären Cache gespeicherten Datei, und der Inhalt wird nicht aktualisiert. Wenn BlobFuse die neueste Datei heruntergeladen hat und Sie weiterhin veraltete Inhalte beobachten, löschen Sie den Kernelseitencache mithilfe des sysctl -w vm.drop_caches=3 Befehls manuell.

Wenn Ihr Workflow die Datei direkt im Container aktualisiert (nicht blobFuse verwendet), und Sie die neuesten Inhalte auf der BlobFuse-Bereitstellung abrufen möchten, führen Sie die folgenden Schritte aus (nur für Fuse3-kompatible Linux-Verteilungen):

• Legen Sie alle Timeouts im Libfuse-Abschnitt auf 0 fest (Eintrag, Attribut, negativ).

• Entfernen Sie attr_cache aus Ihrem Pipelineabschnitt in der Konfiguration.

• Legen Sie "Dateicache-Timeout" auf "0" fest.

• Fügen Sie im Abschnitt "libfuse" Ihrer Konfigurationsdatei "disable-writeback-cache: true" hinzu.

BlobFuse-Gesundheitsüberwachung

Eines der BlobFuse-Funktionen ist die Zustandsüberwachung. Es bietet mehr Einblick in das Verhalten Ihrer BlobFuse-Instanz mit dem Rest Ihres Computers. Besuchen Sie hier, um es einzurichten. Diese Funktion steht derzeit als Vorschau zur Verfügung.

Probleme mit build

Stellen Sie sicher, dass Sie Ihre Go-Entwicklungsumgebung ordnungsgemäß einrichten. Stellen Sie sicher, dass Sie fuse3 oder fuse2 installieren, z. B.:

sudo apt-get install fuse3 libfuse3-dev -y

Probleme mit privaten Endpunkten für hierarchische Namespace-aktivierte Speicherkonten

Wenn Sie auf ein hierarchisches Namespace-fähiges Azure-Speicherkonto hinter privaten Endpunkten zugreifen, müssen Sie zwei separate private Endpunkte erstellen, um eine ordnungsgemäße Konnektivität sicherzustellen:

1. Privater Endpunkt für DFS

   • Ziel: privatelink.dfs.core.windows.net
     • Verwenden Sie diesen Endpunkt, um auf die Data Lake Storage Gen2-Funktionalität zuzugreifen.

2. Privater Endpunkt für Blob

   • Ziel: privatelink.blob.core.windows.net
   • Verwenden Sie diesen Endpunkt, um auf Blob Storage-Vorgänge zuzugreifen.

Warum Sie beide Endpunkte benötigen

Hierarchische namespacefähige Speicherkonten verwenden separate Endpunkte für BLOB- und DFS-Vorgänge:

• Der Data Lake Storage-Endpunkt (dfs.core.windows.net) verarbeitet namespacebezogene Vorgänge wie Verzeichnis- und Dateiverwaltung.

• Der Blob Storage-Endpunkt (blob.core.windows.net) verarbeitet Vorgänge wie das Streamen von Daten in und aus Blobs.

Siehe auch

• Aktivieren von Protokollen für BlobFuse
• Problembehandlung bei BlobFuse
• Bekannte Probleme mit BlobFuse
• BlobFuse häufig gestellte Fragen
• Was ist BlobFuse?