Software Data Domain : Discrepanza tra l'utilizzo segnalato da "filesys show space (df)" e i totali sfs_dump
Summary: Alcuni clienti sommano il valore "post-lc-size" (dimensione post-compressione) di tutti i file segnalati da "sfs_dump" e si aspettano che corrisponda all'utilizzo dello spazio riportato da "filesys show space" (df). Poiché questi due valori non corrispondono, possono vedere la differenza come "spazio mancante o non contabilizzato" ...
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
Lo scopo di "sfs_dump" (o filesys show compression) è quello di aiutare a ottenere un'idea della compressione ottenuta per un file al momento dell'acquisizione. Non ha lo scopo di riflettere lo spazio complessivo utilizzato.
La somma delle dimensioni post-compressione di tutti i file segnalate da "sfs_dump" corrisponderà all'utilizzo totale dello spazio solo se non sono mai state eseguite eliminazioni sul file system. Questo non accade mai su un DDR di produzione, quindi l'utilizzo di "sfs_dump" per tenere conto dell'utilizzo corrente dello spazio è un errore. Illustreremo questo aspetto con un esempio di seguito.
ILLUSTRAZIONE:
Questo può essere facilmente visto con un semplice esempio in tre passaggi:
Come illustrato in precedenza, la dimensione di post-compressione è 10G.
II. Successivamente, eseguo il backup di un altro file 10G (file2). Si tratta di un file 1 molto simile o uguale a
Come visto sopra, file2 non ha occupato spazio aggiuntivo in quanto è stato deduplicato completamente con file1.
III. A questo punto, elimino File1 ed eseguo nuovamente "sfs_dump" sull mtree.
In base a quanto sopra, il cliente può prevedere che non venga consumato spazio sul file system. L'unico file nell MTree occupa 0 byte dopo la compressione (la sommatoria di tutti i file riportati da sfs_dump è 0 byte). Ma questo è un errore. L'utilizzo dello spazio sul sistema è effettivamente 10G ed è accuratamente riflesso da df.
Ciò è dovuto al fatto che File2 fa riferimento a tutti i segmenti originariamente scritti da File1. L'eliminazione di File1 non ha liberato nulla. "sfs_dump" non mostra il File1 originale perché è stato eliminato.
La somma delle dimensioni post-compressione di tutti i file segnalate da "sfs_dump" corrisponderà all'utilizzo totale dello spazio solo se non sono mai state eseguite eliminazioni sul file system. Questo non accade mai su un DDR di produzione, quindi l'utilizzo di "sfs_dump" per tenere conto dell'utilizzo corrente dello spazio è un errore. Illustreremo questo aspetto con un esempio di seguito.
ILLUSTRAZIONE:
Questo può essere facilmente visto con un semplice esempio in tre passaggi:
- Eseguo il backup di un file (file1) che è 10G. Diciamo che questa è una scatola nuova di zecca e niente con cui deduplicare. Anche la dimensione post-compressione è quindi di circa 10G.
# sfs_dump /data/col1/test/ /data/col1/test/file1: mtime: 1503023531690895000 ID file: 18 taglia: 10736790004 tipo: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 0 (0%) pre_lc_size: 10772785048 post_lc_size: Modalità 10942680452 (102%): 02000100644
Come illustrato in precedenza, la dimensione di post-compressione è 10G.
II. Successivamente, eseguo il backup di un altro file 10G (file2). Si tratta di un file 1 molto simile o uguale a
# sfs_dump /data/col1/test /data/col1/test/file1: mtime: 1503023531690895000 ID file: 18 taglia: 10736790004 tipo: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 0 (0%) pre_lc_size: 10772785048 post_lc_size: Modalità 10942680452 (102%): 02000100644 /data/col1/test/file2: mtime: 1503023531690895000 ID file: 19 taglia: 10736790004 tipo: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 1282587 (100%) pre_lc_size: 0 post_lc_size: Modalità 0 (0%): 02000100644
Come visto sopra, file2 non ha occupato spazio aggiuntivo in quanto è stato deduplicato completamente con file1.
III. A questo punto, elimino File1 ed eseguo nuovamente "sfs_dump" sull mtree.
# sfs_dump /data/col1/test /data/col1/test/file2: mtime: 1503023531690895000 ID file: 19 taglia: 10736790004 tipo: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 1282587 (100%) pre_lc_size: 0 post_lc_size: Modalità 0 (0%): 02000100644
In base a quanto sopra, il cliente può prevedere che non venga consumato spazio sul file system. L'unico file nell MTree occupa 0 byte dopo la compressione (la sommatoria di tutti i file riportati da sfs_dump è 0 byte). Ma questo è un errore. L'utilizzo dello spazio sul sistema è effettivamente 10G ed è accuratamente riflesso da df.
Ciò è dovuto al fatto che File2 fa riferimento a tutti i segmenti originariamente scritti da File1. L'eliminazione di File1 non ha liberato nulla. "sfs_dump" non mostra il File1 originale perché è stato eliminato.
# df Tier attivo: Dimensione risorsa GiB usati GiB disp. GiB uso% GiB pulibili* ---------------- -------- -------- --------- ---- -------------- /dati: pre-comp - 10.0 - - - /dati: post-comp 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.