Oprogramowanie Data Domain: Rozbieżność między użyciem zgłoszonym przez "filesys show space (df)" a sumą sfs_dump
Summary: Niektórzy klienci sumują rozmiar po kompresji wszystkich plików zgłoszony przez polecenie "sfs_dump" i oczekują, że będzie on zgodny z wykorzystaniem miejsca zgłoszonym przez "filesys show space" (df). Ponieważ te dwie wartości nie są zgodne, mogą zobaczyć różnicę jako "brakujące lub nierozliczone miejsce" ...
Instructions
Suma rozmiaru po kompresji wszystkich plików zgłoszona przez "sfs_dump" będzie odpowiadać całkowitemu wykorzystaniu miejsca tylko wtedy, gdy w systemie plików nigdy nie zostały usunięte. To nigdy nie ma miejsca w produkcyjnym DDR, więc używanie "sfs_dump" do uwzględnienia bieżącego wykorzystania przestrzeni jest błędem. Zilustrujemy to na przykładzie poniżej.
ILUSTRACJA:
Można to łatwo zauważyć na prostym, trzyetapowym przykładzie:
- Kopię zapasową pliku (file1) o rozmiarze 10G. Powiedzmy, że jest to zupełnie nowe pudełko i nie ma nic do zduplikowania. Rozmiar po kompresji wynosi zatem również około 10G.
# sfs_dump /data/kol1/test/ /data/coll1/test/plik1: mtime: 1503023531690895000 fileid: Rozmiar 18: Typ 10736790004: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 0 (0%) pre_lc_size: 10772785048 post_lc_size: Tryb 10942680452 (102%): 02000100644
Jak widać powyżej, rozmiar kompresji po wyniesieniu wynosi 10G.
II. Następnie wykonam kopię zapasową kolejnego pliku 10G (plik2). Jest on bardzo podobny lub taki sam jak plik1.
# sfs_dump /data/kol1/test /data/coll1/test/plik1: mtime: 1503023531690895000 fileid: Rozmiar 18: Typ 10736790004: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 0 (0%) pre_lc_size: 10772785048 post_lc_size: Tryb 10942680452 (102%): 02000100644 /data/col1/test/plik2: mtime: 1503023531690895000 fileid: 19 rozmiar: Typ 10736790004: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 1282587 (100%) pre_lc_size: 0 post_lc_size: Tryb 0 (0%): 02000100644
Jak widać powyżej, plik2 nie zajmował dodatkowego miejsca, ponieważ całkowicie deduplikował się z plikiem file1.
III. Teraz usuwam plik1 i ponownie uruchamiam "sfs_dump" dla drzewa MTree.
# sfs_dump /data/kol1/test /data/col1/test/plik2: mtime: 1503023531690895000 fileid: 19 rozmiar: Typ 10736790004: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 1282587 (100%) pre_lc_size: 0 post_lc_size: Tryb 0 (0%): 02000100644
W związku z powyższym klient może oczekiwać, że w systemie plików nie powinno być zajmowane żadne miejsce. Jedyny plik w drzewie MTree zajmuje 0 bajtów po kompresji (suma wszystkich plików zgłoszonych przez sfs_dump wynosi 0 bajtów). Jest to jednak błędne przekonanie. Wykorzystanie przestrzeni w systemie wynosi w rzeczywistości 10G i jest dokładnie odzwierciedlone przez df .
Dzieje się tak, ponieważ Plik2 odwołuje się do wszystkich segmentów pierwotnie napisanych przez Plik1. Usunięcie Pliku1 niczego nie zwolniło. "sfs_dump" nie pokazuje oryginalnego pliku File1, ponieważ został on usunięty.
# df Warstwa aktywna: Rozmiar zasobu GiB Używane GiB Dostępność GiB Use% Możliwe do oczyszczenia GiB* ---------------- -------- -------- --------- ---- -------------- /dane: pre-comp - 10.0 - - - /dane: po komp. 129479,5 10,7 129468,8 0% 10,2