Pourquoi un NAS indique-t-il de l’espace libre, mais refuse-t-il les nouveaux fichiers volumineux ?

Un NAS peut afficher une capacité disponible suffisante tout en refusant un fichier volumineux lorsque le quota de destination, les métadonnées, la limite de fichiers ou l’espace allouable accessible en écriture est épuisé.

Le tableau de bord peut indiquer l’espace disponible à l’échelle du pool alors que le partage appartient à un jeu de données plus petit, à un volume fin, à un quota utilisateur, à un système de fichiers réservé ou à un profil de métadonnées presque épuisé. Un envoi volumineux peut également nécessiter de l’espace temporaire, une seconde copie ou une taille de fichier unique que le système de fichiers de destination ne peut pas gérer. Commencez par le chemin exact qui échoue et le code d’erreur, au lieu de supposer que le chiffre général de l’espace libre décrit l’opération.

Identifiez le système de fichiers et la limite réellement utilisés par le partage

Faites correspondre le partage SMB ou l’application à son chemin hôte, son point de montage, son jeu de données, son sous-volume, son volume fin et son pool sous-jacent. Notez les blocs disponibles, les i-nœuds libres, l’identité de l’utilisateur et la taille du fichier rejeté.

GNU explique que df indique le système de fichiers monté associé à un chemin, et non l’ensemble des pools, quotas, instantanés ou limites applicatives qui se trouvent au-dessus ou au-dessous de celui-ci.

Si le partage écrit sur une partition système ou un jeu de données monté de plus petite taille, l’espace libre global du pool n’est pas pertinent. Corrigez le chemin ou le montage avant de supprimer des données sur la mauvaise couche de stockage.

Vérifiez les quotas utilisateur, de groupe, de jeu de données et de partage

Comparez la vue de l’espace libre de l’administrateur avec le quota appliqué à l’utilisateur SMB, au groupe, au jeu de données, au projet ou au dossier partagé concerné. Effectuez le test avec le même compte que celui qui reçoit l’erreur.

Oracle indique que les quotas et réservations ZFS peuvent limiter un jeu de données même si de l’espace inutilisé reste dans le pool, ou réserver la capacité disponible pour un autre jeu de données.

Ne supprimez pas les quotas globalement. Augmentez uniquement la limite dont la restriction est avérée, ou déplacez le fichier vers un jeu de données dont la politique de capacité correspond à la charge de travail.

Comparez l’espace des données aux métadonnées et à l’espace de travail d’allocation

Inspectez les données, les métadonnées, l’allocation système, les groupes de blocs et les compteurs de réservation propres au système de fichiers. La création d’un fichier volumineux peut nécessiter des mises à jour de métadonnées et un espace de travail pour la copie sur écriture, en plus des octets du contenu.

La documentation de Btrfs indique qu’il peut renvoyer ENOSPC malgré un espace libre visible lorsque ses besoins d’allocation et de copie sur écriture ne peuvent pas être satisfaits.

Si les métadonnées sont limitées, utilisez les outils de diagnostic pris en charge par le système de fichiers et des actions de récupération ciblées. Ne remplissez pas l’espace restant avec un autre fichier de test volumineux et ne lancez pas d’équilibrage sans filtre avant d’avoir évalué l’espace de travail nécessaire.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Vérifiez les i-nœuds et les limites d’enregistrements de fichiers

Notez le nombre d’i-nœuds ou d’enregistrements de fichiers disponibles et comptez les petits fichiers présents dans les caches, les magasins de courriels, les miniatures, les paquets extraits et les répertoires d’applications. Une grande capacité en octets ne garantit pas qu’une nouvelle entrée de répertoire ou qu’un nouvel enregistrement de métadonnées puisse être alloué.

La présentation des systèmes de fichiers de Red Hat explique que XFS alloue dynamiquement les i-nœuds et que les implémentations de systèmes de fichiers possèdent des limites distinctes pour les i-nœuds et les enregistrements de fichiers.

Si les i-nœuds sont épuisés, supprimez ou archivez un cache à nombre élevé après vérification, en passant par l’application qui le gère. Supprimer un seul fichier volumineux ne résoudra pas un manque d’enregistrements de fichiers.

Vérifiez la taille maximale des fichiers et le format de destination

Identifiez le système de fichiers de destination et comparez la taille maximale d’un fichier unique à celle du fichier envoyé. Prenez également en compte les disques amovibles de transit, les destinations de sauvegarde USB et les dossiers temporaires des applications.

La présentation de NTFS par Microsoft montre que la taille maximale d’un fichier dépend de la conception du système de fichiers et des paramètres d’allocation. L’espace libre total ne permet donc pas de contourner la limite d’un format pour un fichier unique.

Si l’échec se produit près d’un seuil constant, comme 4 Go, inspectez chaque système de fichiers intermédiaire et chaque étape du chemin d’envoi. Le reformatage détruit les données : migrez les fichiers vérifiés ailleurs avant de modifier le format de destination.

Évaluez les besoins en espace temporaire, fichiers creux et préallocation

Vérifiez si l’outil d’envoi écrit un fichier temporaire, préalloue la destination complète, conserve l’ancienne version jusqu’au renommage ou décompresse une archive dans des fichiers supplémentaires. Mesurez l’allocation maximale plutôt que la taille finale du fichier.

L’appel système fallocate réserve l’espace disque afin d’éviter que les écritures ultérieures échouent par manque de capacité. Une application peut donc refuser un fichier volumineux avant d’avoir transféré toutes ses données.

Choisissez un répertoire temporaire situé sur le pool de données prévu ou désactivez la préallocation uniquement si l’application le permet sans risque. Conservez une marge suffisante pour le fichier d’origine, la copie temporaire, les métadonnées et les instantanés pendant le remplacement.

Reproduisez l’erreur exacte avec un fichier contrôlé

Créez des fichiers de test dont la taille est inférieure puis supérieure à la taille qui échoue, en utilisant le même utilisateur, le même protocole, le même chemin et la même application. Capturez l’erreur du client et le journal du serveur sans retenter à plusieurs reprises l’envoi du fichier de production.

Le guide ZimaSpace consacré à la recherche d’une utilisation inattendue de l’espace NAS fournit la méthode complémentaire pour faire correspondre les dossiers visibles à l’allocation réelle du système de fichiers.

Le problème est résolu lorsque la limite avérée — quota, métadonnées, i-nœuds, format ou espace temporaire — est corrigée et qu’un fichier dépassant l’ancienne taille d’échec peut être écrit, fermé, rouvert et vérifié avec succès. Arrêtez les écritures si le système de fichiers passe en lecture seule ou signale une corruption ou des erreurs matérielles.