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" ...

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

Celem polecenia "sfs_dump" (lub "filesys show compression") jest ułatwienie zrozumienia kompresji pliku w momencie pozyskiwania. Nie ma na celu odzwierciedlenia ogólnej ilości zajmowanego miejsca.

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:
 
  1.  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

 

Products

DD OS 5.5, DD OS 5.6, DD OS 6.0, DD OS 6.1, DD OS Previous Versions
Article 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.