Software Data Domain: Jak se vyznat v nesrovnalostech mezi využitím hlášeným Df a Sfs_dump součty
Summary: Někteří zákazníci sčítají "post-lc-size" (velikost po kompresi) všech souborů hlášených "sfs_dump". A očekávají, že bude odpovídat využití místa, které hlásí "filesys show space" (df). Vzhledem k tomu, že se tyto dvě hodnoty neshodují, mohou vidět rozdíl jako "chybějící nebo nezapočítané místo" ...
Instructions
Účelem "sfs_dump" (nebo filesys show compression) je pomoci získat představu o kompresi dosažené pro soubor v době ingestování. Nemá odrážet celkový spotřebovaný prostor.
Součet post-kompresních velikostí všech souborů hlášených "sfs_dump" odpovídá celkovému využití místa pouze v případě, že v souborovém systému nikdy nebyla provedena žádná odstranění. U produkčního zařízení DDR tomu tak nikdy není, takže použití "sfs_dump" k zohlednění aktuálního využití místa je chyba. Ilustrujeme to na níže uvedeném příkladu.
OBRÁZEK:
To je vidět na jednoduchém příkladu ve třech krocích:
-
Zálohuji soubor (file1) ve formátu 10G. Řekněme, že se jedná o zbrusu novou krabici a není co deduplikovat. Velikost po kompresi je tedy také kolem 10 G.
# sfs_dump /data/col1/test/ /data/col1/test/file1: mtime: 1503023531690895000 fileid: 18 size: 10736790004 type: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 0 (0%) pre_lc_size: 10772785048 post_lc_size: 10942680452 (102%) mode: 02000100644Jak je vidět výše, velikost komprese příspěvku je 10 G.
-
Dále zálohuji další soubor 10G (file2) Tento soubor je podobný nebo stejný jako file1.
# sfs_dump /data/col1/test /data/col1/test/file1: mtime: 1503023531690895000 fileid: 18 size: 10736790004 type: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 0 (0%) pre_lc_size: 10772785048 post_lc_size: 10942680452 (102%) mode: 02000100644 /data/col1/test/file2: mtime: 1503023531690895000 fileid: 19 size: 10736790004 type: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 1282587 (100%) pre_lc_size: 0 post_lc_size: 0 (0%) mode: 02000100644
Jak je vidět výše, file2 nezabral žádné další místo, protože se zcela deduplikoval pomocí file1.
-
Nyní odstraním File1 a znovu spustím "sfs_dump" na mtree.
# sfs_dump /data/col1/test /data/col1/test/file2: mtime: 1503023531690895000 fileid: 19 size: 10736790004 type: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 1282587 (100%) pre_lc_size: 0 post_lc_size: 0 (0%) mode: 02000100644
Na základě výše uvedeného může zákazník očekávat, že v systému souborů nebude spotřebováváno žádné místo. Jediný soubor ve fondu MTree zabírá 0 bajtů po komprimaci (součet všech souborů hlášených sfs_dump je 0 bajtů). Ale to je omyl. Využití prostoru v systému je ve skutečnosti 10G a df to přesně odráží.
Je to proto, že File2 odkazuje na všechny segmenty původně zapsané File1. Odstraněním souboru File1 se nic
neuvolnilo sfs_dump" nezobrazuje původní soubor File1, protože byl odstraněn.
# df Active Tier: Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB* ---------------- -------- -------- --------- ---- -------------- /data: pre-comp - 10.0 - - - /data: post-comp 129479.5 10.7 129468.8 0% 10.2