Logiciel Data Domain : Écart entre l’utilisation signalée par « filesys show space (df) » et les totaux de sfs_dump
Summary: Certains clients additionnent la « taille post-lc » (taille post-compression) de tous les fichiers signalés par « sfs_dump » et s’attendent à ce qu’elle corresponde à l’utilisation de l’espace signalée par « filesys show space » (df). Comme ces deux valeurs ne correspondent pas, ils peuvent voir la différence comme « espace manquant ou non pris en compte » ...
This article applies to
This article does not apply to
This article is not tied to any specific product.
Not all product versions are identified in this article.
Instructions
L’objectif de « sfs_dump » (ou filesys show compression) est d’aider à obtenir une idée de la compression obtenue pour un fichier au moment de l’acquisition. Il n’est pas destiné à refléter l’espace total utilisé.
La somme de la taille après compression de tous les fichiers signalée par « sfs_dump » correspondra à l’utilisation totale de l’espace uniquement si aucune suppression n’a jamais été effectuée sur le système de fichiers. Ce n’est jamais le cas sur un DDR de production. Par conséquent, l’utilisation de « sfs_dump » pour tenir compte de l’utilisation actuelle de l’espace est erronée. Nous allons illustrer cela avec un exemple ci-dessous.
ILLUSTRATION:
Cela peut être facilement vu avec un exemple simple en trois étapes :
Comme indiqué ci-dessus, la taille de post-compression est de 10G.
II. Ensuite, je sauvegarde un autre fichier 10G (file2). Il s’agit d’une erreur très similaire ou identique à celle du fichier 1.
Comme indiqué ci-dessus, file2 n’a pas pris d’espace supplémentaire car il a été complètement dédupliqué avec file1.
III. Maintenant, je supprime File1 et j’exécute à nouveau « sfs_dump » sur la mtree.
Sur la base de ce qui précède, le client peut s’attendre à ce qu’aucun espace ne soit consommé sur le système de fichiers. Le seul fichier de la structure mtree occupe 0 octet après compression (la somme de tous les fichiers signalés par sfs_dump est de 0 octet). Mais c’est une erreur. L’utilisation de l’espace sur le système est en fait de 10G et est reflétée avec précision par df .
Cela est dû au fait que File2 fait référence à tous les segments écrits à l’origine par File1. La suppression de File1 n’a rien libéré. « sfs_dump » n’affiche pas le fichier File1 d’origine, car il a été supprimé.
La somme de la taille après compression de tous les fichiers signalée par « sfs_dump » correspondra à l’utilisation totale de l’espace uniquement si aucune suppression n’a jamais été effectuée sur le système de fichiers. Ce n’est jamais le cas sur un DDR de production. Par conséquent, l’utilisation de « sfs_dump » pour tenir compte de l’utilisation actuelle de l’espace est erronée. Nous allons illustrer cela avec un exemple ci-dessous.
ILLUSTRATION:
Cela peut être facilement vu avec un exemple simple en trois étapes :
- Je sauvegarde un fichier (file1) de 10G. Disons qu’il s’agit d’une toute nouvelle boîte et qu’il n’y a rien à dédupliquer. La taille post-compression est donc également d’environ 10G.
# sfs_dump /data/col1/test/ /data/col1/test/file1 : mtime : 1503023531690895000 fileid : 18 Taille : Type de 10736790004 : 9 seg_bytes : 10772785048 seg_count : 1282587 redun_seg_count : 0 (0 %) pre_lc_size : 10772785048 post_lc_size : 10942680452 (102 %) : 02000100644
Comme indiqué ci-dessus, la taille de post-compression est de 10G.
II. Ensuite, je sauvegarde un autre fichier 10G (file2). Il s’agit d’une erreur très similaire ou identique à celle du fichier 1.
# sfs_dump /data/col1/test /data/col1/test/file1 : mtime : 1503023531690895000 fileid : 18 Taille : Type de 10736790004 : 9 seg_bytes : 10772785048 seg_count : 1282587 redun_seg_count : 0 (0 %) pre_lc_size : 10772785048 post_lc_size : 10942680452 (102 %) : 02000100644 /data/col1/test/file2 : mtime : 1503023531690895000 fileid : 19 taille : Type de 10736790004 : 9 seg_bytes : 10772785048 seg_count : 1282587 redun_seg_count : 1282587 (100 %) pre_lc_size : 0 post_lc_size : Mode 0 (0 %) : 02000100644
Comme indiqué ci-dessus, file2 n’a pas pris d’espace supplémentaire car il a été complètement dédupliqué avec file1.
III. Maintenant, je supprime File1 et j’exécute à nouveau « sfs_dump » sur la mtree.
# sfs_dump /data/col1/test /data/col1/test/file2 : mtime : 1503023531690895000 fileid : 19 taille : Type de 10736790004 : 9 seg_bytes : 10772785048 seg_count : 1282587 redun_seg_count : 1282587 (100 %) pre_lc_size : 0 post_lc_size : Mode 0 (0 %) : 02000100644
Sur la base de ce qui précède, le client peut s’attendre à ce qu’aucun espace ne soit consommé sur le système de fichiers. Le seul fichier de la structure mtree occupe 0 octet après compression (la somme de tous les fichiers signalés par sfs_dump est de 0 octet). Mais c’est une erreur. L’utilisation de l’espace sur le système est en fait de 10G et est reflétée avec précision par df .
Cela est dû au fait que File2 fait référence à tous les segments écrits à l’origine par File1. La suppression de File1 n’a rien libéré. « sfs_dump » n’affiche pas le fichier File1 d’origine, car il a été supprimé.
# df Niveau actif : Resource Size GiB Used GiB Avail GiB Use % Cleanable GiB* ---------------- -------- -------- --------- ---- -------------- /data : pre-comp - 10.0 - - - /données : après compression 129479,5 10,7 129468,8 0 % 10,2
Products
DD OS 5.5, DD OS 5.6, DD OS 6.0, DD OS 6.1, DD OS Previous VersionsArticle Properties
Article Number: 000022756
Article Type: How To
Last Modified: 08 Oct 2024
Version: 3
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.