Comment vérifier si l’espace NAS est utilisé par des instantanés ou des fichiers en direct

Oui, vous pouvez les distinguer en comparant l’espace utilisé par le dataset, l’espace référencé ou logique, l’espace retenu par les snapshots et l’espace libre du pool au même instant.

La décision est importante lorsqu’un NAS signale beaucoup moins d’espace libre que ne semblent en contenir les dossiers visibles. Les deux états possibles sont l’allocation active du dataset et les blocs conservés uniquement par les snapshots. Commencez par une configuration enregistrée et des données jetables, observez une seule branche à la fois et arrêtez-vous si le test augmente les risques de perte de données, de permissions ou de disponibilité.

Définir les conditions à l’origine de la décision entre espace des snapshots et espace des fichiers actifs

Consignez l’environnement avant toute modification : versions des logiciels et des micrologiciels, identités des appareils, chemin de montage ou chemin réseau, espace libre, permissions et symptôme observable. La référence doit conserver suffisamment de détails pour reproduire le fait qu’un NAS signale beaucoup moins d’espace libre que ne semblent en contenir les dossiers visibles.

Le premier scénario possible est l’allocation active du dataset. Le second concerne les blocs conservés uniquement par les snapshots. La documentation actuelle sur les propriétés d’espace OpenZFS définit le mécanisme ou la limite de commande utilisés dans le test ; elle ne remplace pas l’observation de ce serveur domestique précis.

Rédigez la condition d’acceptation et la condition d’arrêt avant d’exécuter le test discriminant. Une réussite doit modifier les éléments probants prédits par une branche tout en laissant les services non concernés inchangés ; un échec doit ramener le système à l’état enregistré plutôt que déclencher une série de corrections spéculatives.

Tester l’hypothèse sans réduire l’exigence initiale

Utilisez ce test discriminant : consignez les informations de comptabilisation du pool et du dataset, supprimez un fichier volumineux jetable, puis comparez l’état avant et après sans détruire les snapshots. Conservez la charge, le client, le chemin, l’ensemble de fichiers et le calendrier afin que le résultat puisse être attribué à la variable modifiée.

Utilisez la comptabilisation des allocations ZFS pour sélectionner le champ capable de distinguer réellement les deux branches, puis capturez son horodatage, son code de sortie, le texte d’erreur, l’identité de l’appareil ou du snapshot, la latence, les octets transférés, les permissions et l’état de récupération. Une sortie de commande réussie ne suffit pas lorsque l’identité, la durabilité ou l’état de l’application constitue l’hypothèse testée.

Répétez le test une fois après un redémarrage, une reconnexion, un remontage ou une purge du cache lorsque cet événement fait partie de la condition initiale. Si la première exécution est destructive ou si l’environnement ne peut pas être restauré, arrêtez-vous et reproduisez-la sur une copie jetable.

zfs list -o name,used,refer,usedbysnapshots,usedbydataset,usedbychildren

Interpréter les résultats de réussite, d’échec et d’exception

RÉUSSITE : l’espace référencé actif diminue tandis que l’espace utilisé reste stable parce qu’un snapshot référence toujours les blocs. Consignez la version exacte, l’identité et la charge qui ont produit cette réussite afin que la conclusion reste conditionnelle plutôt que de devenir une affirmation universelle.

ÉCHEC : l’espace référencé et l’espace utilisé restent tous deux élevés, ou un autre dataset, clone, quota réservé ou allocation de métadonnées possède l’espace. Un échec ne prouve pas automatiquement la branche opposée lorsque le réseau, la mémoire, les permissions ou la cohérence de la source peuvent influencer les deux ; isolez ces dépendances communes avant d’aller plus loin.

RÉSULTAT EXCEPTIONNEL OU AMBIGU : arrêtez les suppressions et répertoriez chaque dataset, snapshot, clone et réservation avant tout nettoyage. Conservez les journaux et n’exécutez aucune commande de réparation, d’élagage, de destruction, de repartitionnement ou de modification récursive des propriétaires tant qu’une copie récupérable n’existe pas.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Confirmer la décision avec la charge initiale

Appliquez l’action correspondant à la branche observée, puis reproduisez la condition initiale plutôt qu’un substitut simplifié. La décision n’est valide que lorsque l’espace référencé actif diminue tandis que l’espace utilisé reste stable parce qu’un snapshot référence toujours les blocs, sur deux cycles ou lors du redémarrage, de la mise en veille, de l’interruption ou du changement de charge pertinent.

Utilisez les fenêtres de sauvegarde immuables pour vérifier le flux de travail dépendant le plus proche, tout en conservant le déclencheur initial inchangé. Les datasets, partages, conteneurs, utilisateurs et points de récupération non concernés doivent conserver leur accès et leur calendrier précédents.

La limite d’arrêt est explicite : si l’espace référencé et l’espace utilisé restent tous deux élevés, ou si un autre dataset, clone, quota réservé ou allocation de métadonnées possède l’espace, revenez à la dernière configuration vérifiée, conservez les éléments probants et ne lancez un test plus approfondi de la plateforme ou du matériel que lorsque la branche est reproductible.

Une fois le résultat cible confirmé, comparez-le avec la cadence de vérification des sauvegardes afin que la correction ne transfère pas le risque vers un service voisin. Un test cible réussi accompagné d’une nouvelle défaillance de sauvegarde, d’identité, de délai d’attente ou de disponibilité reste une modification échouée.

FAQ

Concernant l’espace des snapshots par rapport à celui des fichiers actifs, les recherches restantes portent généralement sur les raisons pour lesquelles la suppression d’un fichier ne libère pas d’espace dans le pool, sur la question de savoir si logicalused correspond à l’espace physique et sur la possibilité de prévoir l’espace des snapshots avant la suppression. Les réponses ci-dessous séparent ces cas particuliers de la décision principale.

La limite d’acceptation ne change pas : l’espace référencé actif diminue tandis que l’espace utilisé reste stable parce qu’un snapshot référence toujours les blocs. Si une condition ultérieure modifie le système de fichiers, l’identité, le chemin réseau ou la version de l’application, répétez uniquement le test discriminant concerné par cette modification.

Arrêtez d’élargir l’expérience lorsque l’espace référencé et l’espace utilisé restent tous deux élevés, ou lorsqu’un autre dataset, clone, quota réservé ou allocation de métadonnées possède l’espace. À ce stade, arrêtez les suppressions et répertoriez chaque dataset, snapshot, clone et réservation avant tout nettoyage ; conservez les éléments probants avant de transmettre le problème au responsable de la plateforme, du stockage ou du matériel.

Pourquoi la suppression d’un fichier ne libère-t-elle pas d’espace dans le pool ?

Un snapshot peut encore référencer ses blocs, ou un clone, une réservation ou un autre dataset peut posséder l’allocation.

logicalused correspond-il à l’espace physique ?

Non. La compression, les copies, les métadonnées et le partage font diverger les valeurs logiques et allouées.

Peut-on prévoir l’espace des snapshots avant la suppression ?

Les propriétés d’espace référencé et d’espace unique sont utiles, mais les blocs partagés signifient que l’espace récupéré dépend de l’ensemble de la chaîne de snapshots.

Pour l’espace des snapshots par rapport à celui des fichiers actifs, la réponse pratique reste conditionnelle : l’espace référencé actif diminue tandis que l’espace utilisé reste stable parce qu’un snapshot référence toujours les blocs. Lorsque l’espace référencé et l’espace utilisé restent tous deux élevés, ou lorsqu’un autre dataset, clone, quota réservé ou allocation de métadonnées possède l’espace, arrêtez les suppressions et répertoriez chaque dataset, snapshot, clone et réservation avant tout nettoyage ; une réussite partielle qui ne résiste pas à la charge initiale n’est pas une compatibilité.