Object Storage Service:FAQ ossfs 2.0

Erreur de montage : Échec du montage d'ossfs2

Analyse du problème : Il s'agit d'une erreur générique. Consultez les journaux pour obtenir des détails spécifiques. Cette erreur est généralement causée par des permissions incorrectes ou des paramètres de configuration invalides. Par exemple :

2025/03/21 15:09:59.124152|ERROR|th=00007F1238FF5780|ossfs_v2.cpp:1469|Check bucket failed with err: AccessDenied

L'AccessKey utilisé ne dispose pas des permissions nécessaires pour accéder au bucket. Vérifiez que votre AccessKey possède les permissions requises et que le nom du bucket est correct.

2025/03/21 15:14:29.671470|ERROR|th=00007F2304FF5780|ossfs_v2.cpp:1469|Check bucket failed with err: InvalidAccessKeyId

L'AccessKey configuré est invalide.

2025/03/21 15:15:13.805814|ERROR|th=00007FD591D38780|ossfs_v2.cpp:1469|Check bucket failed with err: SignatureDoesNotMatch

Solution : Corrigez la configuration en vous basant sur le message d'erreur présent dans les journaux, puis remontez le système de fichiers.

Erreur de montage : Le répertoire n'existe pas

Analyse du problème : Le répertoire spécifié n'existe pas.

Solution : Créez le répertoire, puis exécutez à nouveau la commande de montage.

Erreur de montage : Le répertoire n'est pas vide

Analyse du problème : ossfs 2,0 exige que le répertoire cible du montage soit vide, or celui spécifié ne l'est pas.

Solution : Vérifiez si un autre système de fichiers est déjà monté sur ce répertoire. Si c'est le cas, démontez-le à l'aide de la commande umount. Si aucun autre système de fichiers n'est monté, supprimez les fichiers résiduels du répertoire. Vous pouvez également choisir un autre répertoire vide pour le montage.

Erreur de montage : version FUSE_3.12' not found

Analyse du problème : Des fichiers d'installation requis sont manquants, ce qui contraint ossfs 2,0 à utiliser la bibliothèque libfuse installée sur le système, laquelle est obsolète.

Solution : Désinstallez le package, puis réinstallez-le.

Erreur de montage : Fuse device not found

Analyse du problème : Le périphérique /dev/fuse n'est pas accessible. Ce problème survient généralement dans un environnement de conteneur qui ne dispose pas des permissions d'accès requises.

Solution : Lors du montage dans un conteneur, démarrez-le en mode privilégié.

Erreur d'écriture : File too large

Analyse du problème : Par défaut, ossfs 2,0 utilise une taille de partie de 8 MiB, ce qui permet de prendre en charge une taille de fichier maximale de 78 125 GiB. Cette erreur se produit lors de l'écriture d'un fichier dépassant cette limite.

Solution : Lors du montage d'un bucket, configurez l'option upload_buffer_size pour augmenter la taille de fichier maximale prise en charge. Notez que la configuration de upload_buffer_size nécessite davantage de ressources mémoire. ossfs 2.0 propose l'option total_mem_limit pour contrôler l'utilisation de la mémoire. Pour plus d'informations, consultez la section Options de montage.

Erreur d'écriture : Invalid argument

Analyse du problème : ossfs 2,0 ne prend pas en charge les écritures aléatoires. Seules les écritures séquentielles ajoutant des données à la fin d'un fichier sont autorisées. Si vous écrivez à une position autre que la fin actuelle du fichier, ossfs 2,0 renvoie une erreur « Invalid argument ». Le journal suivant illustre cet exemple :

2025/04/14 11:00:39.307250|INFO |th=00007FEB88011870|fs.cpp:877|open file /fio/random-write-file.0.0
  nodeid: 5, flags: 32770, read_only: 0, truncate: 0, append: 0
2025/04/14 11:00:39.307551|ERROR|th=00007FEB88011DB0|file.cpp:294|append only file size: 0, offset: 63963136, write_off_: 0

Solution : Si votre application nécessite des écritures aléatoires, migrez vers ossfs 1,0. Dans de nombreux cas, ce qui semble être des écritures aléatoires correspond en réalité à des écritures concurrentes sur le même descripteur de fichier. Si tel est le cas, optez pour des écritures séquentielles monothread. ossfs 2,0 est optimisé pour les écritures séquentielles et offre un débit élevé avec un seul thread.

Échec de git clone dans la cible de montage

Analyse du problème : Par défaut, ossfs 2,0 ne prend pas en charge les lectures et écritures concurrentes sur le même fichier. La lecture d'un fichier pendant son écriture peut renvoyer des données obsolètes ou provoquer une erreur de lecture. La commande git clone utilise un modèle d'accès en lecture-écriture simultanée, susceptible de générer des entrées de journal similaires à celles-ci :

2025/03/21 14:50:52.412572|ERROR|th=00007FE970FF4940|file.cpp:1385|src file /libfuse/.git/objects/pack/tmp_pack_PFRsQf read failed, read : -1, expectRead : 1048576, size_ : 4556308, offset : 0, errno: 2

Dans le journal, errno 2 correspond au code d'erreur Linux ENOENT, indiquant que les données du fichier n'ont pas été lues correctement. Si vous rencontrez des erreurs de lecture avec d'autres applications, vérifiez les journaux pour détecter des messages similaires. Une opération de lecture peut échouer sans renvoyer d'erreur « fichier introuvable » si l'application n'a pas fermé le fichier, empêchant ainsi son téléchargement vers OSS.

Solution : Évitez d'utiliser les commandes concernées. Exécutez git clone sur un disque local, puis utilisez la commande cp pour copier les fichiers vers la cible de montage.

Échec des écritures concurrentes sur le même fichier

Analyse du problème : Lorsque plusieurs descripteurs de fichiers sont ouverts pour le même fichier dans ossfs 2,0, un seul prend en charge les écritures séquentielles. Les opérations d'écriture provenant des autres descripteurs échoueront. Le journal suivant montre un exemple de cette erreur :

2025/03/21 14:59:22.765822|ERROR|th=00007FE990006990|file.cpp:231|file 181 has already been written!

Solution : Évitez les écritures concurrentes sur le même fichier. ossfs 2,0 est optimisé pour les écritures séquentielles, et un seul thread suffit pour assurer un débit élevé.

Erreur de démontage : Target is busy

Analyse du problème : Un processus accédant à un fichier dans le répertoire cible de montage /mnt/ossfs2 bloque l'opération de démontage.

Solution :

1. Utilisez la commande lsof /mnt/ossfs2 pour identifier les processus accédant au répertoire.

2. Arrêtez le processus.

3. Exécutez à nouveau la commande de démontage.

Nombreuses erreurs 404 dans les journaux

Contexte : Les entrées 404 Not Found sont fréquentes dans les journaux d'ossfs 2,0. Dans la plupart des cas, il ne s'agit pas d'erreurs système, mais d'un comportement attendu permettant à ossfs 2,0 d'émuler la sémantique du système de fichiers local.

Avant d'effectuer une opération sur un fichier, le système d'exploitation vérifie si l'objet cible existe. Cette vérification peut déclencher de nombreuses requêtes de sondage vers OSS. Si un objet n'existe pas, OSS renvoie un code d'état 404.

Les étapes suivantes décrivent le processus complet utilisé par ossfs 2,0 pour vérifier l'existence d'un objet :

1. Envoyez une requête GetObjectMeta pour déterminer si un chemin spécifié, tel que object, existe en tant qu'objet réel.

   Si l'objet existe, le système renvoie ses métadonnées. S'il n'existe pas, le système renvoie une erreur 404 et passe à l'étape suivante.

   Remarque

   Même si l'objet n'existe pas, ossfs 2,0 doit toujours déterminer si le chemin correspond à un répertoire.

2. Après réception d'une erreur 404, envoyez une requête ListObjects pour déterminer si le chemin spécifié est un « répertoire », c'est-à-dire pour rechercher des objets ayant le préfixe object/.

   Si le résultat est vide, le chemin n'existe pas. S'il n'est pas vide, le répertoire existe et le système liste son contenu.

Analyse du problème :

• Lorsque vous utilisez une commande telle que stat pour accéder à un fichier inexistant, le système renvoie une erreur 404, qui correspond à l'erreur « No such file or directory » du système de fichiers local.

• Avant de créer des fichiers ou des répertoires par lots, le système d'exploitation vérifie leur existence. Il envoie une requête de création uniquement s'ils n'existent pas. Les erreurs 404 générées lors de cette vérification constituent un comportement attendu et n'indiquent pas une défaillance du système.

Solution : Bien que les erreurs 404 soient attendues, les requêtes de sondage fréquentes dans les scénarios de forte concurrence ou d'opérations par lots peuvent affecter les performances. Utilisez les options suivantes pour optimiser les performances :

1. Augmentez la valeur de --attr_timeout pour prolonger la durée de mise en cache des métadonnées. La durée par défaut est de 60 s.

   Interroger un fichier ou un répertoire avant l'expiration de ses métadonnées évite des requêtes OSS répétées.

2. Configurez --oss_negative_cache_size et --oss_negative_cache_timeout pour activer le cache négatif.

   Lorsqu'un fichier inexistant est interrogé pour la première fois, le résultat est mis en cache en mémoire. Les interrogations ultérieures du même fichier sont servies depuis le cache négatif local jusqu'à son expiration, évitant ainsi d'autres requêtes vers OSS.

   • --oss_negative_cache_size : Nombre d'entrées dans le cache négatif pour les fichiers OSS. La valeur par défaut est 10 000.

   • --oss_negative_cache_timeout : Délai d'expiration du cache négatif pour les fichiers OSS. La valeur par défaut est 0.