Software Data Domain: Discrepancia entre el uso informado por "filesys show space (df)" y los totales de sfs_dump
Summary: Algunos clientes suman el "tamaño posterior a la compresión" de todos los archivos informados por "sfs_dump" y esperan que coincida con la utilización de espacio informada por "filesys show space" (df). Como estos dos valores no coinciden, pueden ver la diferencia como "espacio faltante o no contabilizado" ...
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
El propósito de "sfs_dump" (o filesys show compression) es ayudar a tener una idea de la compresión lograda para un archivo en el momento de la ingesta. No se pretende reflejar el espacio total consumido.
La suma del tamaño posterior a la compresión de todos los archivos informados por "sfs_dump" coincidirá con la utilización del espacio total solo si no se han realizado eliminaciones en el sistema de archivos. Este nunca es el caso en un DDR de producción, por lo que usar "sfs_dump" para tener en cuenta la utilización del espacio actual es una falacia. Ilustraremos esto con un ejemplo a continuación.
ILUSTRACIÓN:
Esto se puede ver fácilmente con un ejemplo simple de tres pasos:
Como se vio anteriormente, el tamaño posterior a la compresión es de 10 G.
II. A continuación, hago una copia de seguridad de otro archivo 10G (file2). Esto es muy similar o igual que file1.
Como se vio anteriormente, file2 no ocupó espacio adicional, ya que se deduplicó completamente con file1.
III. Ahora, elimino File1 y vuelvo a ejecutar "sfs_dump" en el mtree.
En función de lo anterior, el cliente puede esperar que no se consuma espacio en el sistema de archivos. El único archivo en el mtree ocupa 0 bytes después de la compresión (la suma de todos los archivos informados por sfs_dump es 0 bytes). Pero esto es una falacia. La utilización del espacio en el sistema es en realidad de 10G y df lo refleja con precisión.
Esto se debe a que File2 hace referencia a todos los segmentos escritos originalmente por File1. La eliminación de File1 no liberó nada. "sfs_dump" no muestra el File1 original porque se eliminó.
La suma del tamaño posterior a la compresión de todos los archivos informados por "sfs_dump" coincidirá con la utilización del espacio total solo si no se han realizado eliminaciones en el sistema de archivos. Este nunca es el caso en un DDR de producción, por lo que usar "sfs_dump" para tener en cuenta la utilización del espacio actual es una falacia. Ilustraremos esto con un ejemplo a continuación.
ILUSTRACIÓN:
Esto se puede ver fácilmente con un ejemplo simple de tres pasos:
- Hago una copia de seguridad de un archivo (file1) que es 10G. Digamos que esta es una caja nueva y no hay nada con lo que desduplicar. Por lo tanto, el tamaño posterior a la compresión también es de alrededor de 10 G.
# sfs_dump /data/col1/test/ /data/col1/test/file1: mtime: 1503023531690895000 fileid: 18 Tamaño: 10736790004 tipo: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 0 (0 %) pre_lc_size: 10772785048 post_lc_size: Modo 10942680452 (102 %): 02000100644
Como se vio anteriormente, el tamaño posterior a la compresión es de 10 G.
II. A continuación, hago una copia de seguridad de otro archivo 10G (file2). Esto es muy similar o igual que file1.
# sfs_dump /data/col1/test /data/col1/test/file1: mtime: 1503023531690895000 fileid: 18 Tamaño: 10736790004 tipo: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 0 (0 %) pre_lc_size: 10772785048 post_lc_size: Modo 10942680452 (102 %): 02000100644 /data/col1/test/file2: mtime: 1503023531690895000 fileid: 19 Tamaño: 10736790004 tipo: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 1282587 (100 %) pre_lc_size: 0 post_lc_size: Modo 0 (0%): 02000100644
Como se vio anteriormente, file2 no ocupó espacio adicional, ya que se deduplicó completamente con file1.
III. Ahora, elimino File1 y vuelvo a ejecutar "sfs_dump" en el mtree.
# sfs_dump /data/col1/test /data/col1/test/file2: mtime: 1503023531690895000 fileid: 19 Tamaño: 10736790004 tipo: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 1282587 (100 %) pre_lc_size: 0 post_lc_size: Modo 0 (0%): 02000100644
En función de lo anterior, el cliente puede esperar que no se consuma espacio en el sistema de archivos. El único archivo en el mtree ocupa 0 bytes después de la compresión (la suma de todos los archivos informados por sfs_dump es 0 bytes). Pero esto es una falacia. La utilización del espacio en el sistema es en realidad de 10G y df lo refleja con precisión.
Esto se debe a que File2 hace referencia a todos los segmentos escritos originalmente por File1. La eliminación de File1 no liberó nada. "sfs_dump" no muestra el File1 original porque se eliminó.
# df Nivel activo: Tamaño del recurso GiB utilizado GiB Uso disponible de GiB % GiB que se puede limpiar* ---------------- -------- -------- --------- ---- -------------- /data: Pre-Comp - 10.0 - - - /data: después de la compresión 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.