Data Domain Software: Uoverensstemmelse mellem forbrug rapporteret af "filesys show space (df)" og sfs_dump totaler
Summary: Nogle kunder lægger "post-lc-størrelsen" (postkomprimeringsstørrelsen) sammen for alle filer, der rapporteres af "sfs_dump", og forventer, at den svarer til den pladsudnyttelse, der rapporteres af "filesys show space" (df). Da disse to værdier ikke stemmer overens, kan de se forskellen som "manglende eller ikke-redegjort plads" ...
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
Formålet med "sfs_dump" (eller filesys viser komprimering) er at hjælpe med at få en fornemmelse af den komprimering, der opnås for en fil på tidspunktet for indtagelse. Det er ikke meningen, at det skal afspejle den samlede forbrugte plads.
Summen af postkomprimeringsstørrelsen af alle filer, der rapporteres af "sfs_dump", svarer kun til den samlede pladsudnyttelse, hvis der aldrig er udført nogen sletninger på filsystemet. Dette er aldrig tilfældet på en produktions-DDR, så det er en fejlslutning at bruge "sfs_dump" til at tage højde for den aktuelle pladsudnyttelse. Vi vil illustrere dette med et eksempel nedenfor.
ILLUSTRATION:
Dette kan let ses med et simpelt tre-trins eksempel:
Som det ses ovenfor, er postkomprimeringsstørrelsen 10G.
II. Dernæst sikkerhedskopierer jeg en anden 10G-fil (fil2). Dette er meget ens eller det samme som fil1.
Som det ses ovenfor, tog file2 ingen ekstra plads, da den de-duplikeret fuldstændigt med file1.
III. Nu sletter jeg File1 og kører "sfs_dump" på mtree igen.
På baggrund af ovenstående kan kunden forvente, at der ikke skal forbruges plads på filsystemet. Den eneste fil i mtree fylder 0 byte efter komprimering (summen af alle filer, der rapporteres af sfs_dump, er 0 byte). Men det er en fejlslutning. Pladsudnyttelsen på systemet er faktisk 10G og afspejles nøjagtigt af df .
Dette skyldes, at File2 refererer til alle segmenter, der oprindeligt blev skrevet af File1. Sletningen af File1 frigjorde intet. "sfs_dump" viser ikke den oprindelige Fil1, fordi den er blevet slettet.
Summen af postkomprimeringsstørrelsen af alle filer, der rapporteres af "sfs_dump", svarer kun til den samlede pladsudnyttelse, hvis der aldrig er udført nogen sletninger på filsystemet. Dette er aldrig tilfældet på en produktions-DDR, så det er en fejlslutning at bruge "sfs_dump" til at tage højde for den aktuelle pladsudnyttelse. Vi vil illustrere dette med et eksempel nedenfor.
ILLUSTRATION:
Dette kan let ses med et simpelt tre-trins eksempel:
- Jeg sikkerhedskopierer en fil (fil1), der er 10G. Sig, at dette er en helt ny boks og intet at de-duplikere med. Postkomprimeringsstørrelsen er derfor også omkring 10G.
# sfs_dump /data/kol1/test/ /data/kol1/test/fil1: mtime: 1503023531690895000 fileid: 18 størrelse: 10736790004 type: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 0 (0%) pre_lc_size: 10772785048 post_lc_size: 10942680452-tilstand (102 %), 02000100644
Som det ses ovenfor, er postkomprimeringsstørrelsen 10G.
II. Dernæst sikkerhedskopierer jeg en anden 10G-fil (fil2). Dette er meget ens eller det samme som fil1.
# sfs_dump /data/kol1/test /data/kol1/test/fil1: mtime: 1503023531690895000 fileid: 18 størrelse: 10736790004 type: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 0 (0%) pre_lc_size: 10772785048 post_lc_size: 10942680452-tilstand (102 %), 02000100644 /data/kol1/test/fil2: mtime: 1503023531690895000 fileid: 19 størrelse: 10736790004 type: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 1282587 (100 %) pre_lc_size: 0 post_lc_size: 0 (0%) tilstand: 02000100644
Som det ses ovenfor, tog file2 ingen ekstra plads, da den de-duplikeret fuldstændigt med file1.
III. Nu sletter jeg File1 og kører "sfs_dump" på mtree igen.
# sfs_dump /data/kol1/test /data/kol1/test/fil2: mtime: 1503023531690895000 fileid: 19 størrelse: 10736790004 type: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 1282587 (100 %) pre_lc_size: 0 post_lc_size: 0 (0%) tilstand: 02000100644
På baggrund af ovenstående kan kunden forvente, at der ikke skal forbruges plads på filsystemet. Den eneste fil i mtree fylder 0 byte efter komprimering (summen af alle filer, der rapporteres af sfs_dump, er 0 byte). Men det er en fejlslutning. Pladsudnyttelsen på systemet er faktisk 10G og afspejles nøjagtigt af df .
Dette skyldes, at File2 refererer til alle segmenter, der oprindeligt blev skrevet af File1. Sletningen af File1 frigjorde intet. "sfs_dump" viser ikke den oprindelige Fil1, fordi den er blevet slettet.
# DF Aktivt niveau: Ressourcestørrelse GiB brugt GiB Benyt GiB Brug% Rengørbar GiB* ---------------- -------- -------- --------- ---- -------------- /data: pre-comp - 10.0 - - - /data: 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.