Data Domain-programvare: Avvik mellom bruk rapportert av "filesys show space (df)" og sfs_dump totaler
Summary: Noen kunder legger sammen "post-lc-size" (post-compression size) for alle filer rapportert av "sfs_dump" og forventer at den samsvarer med plassutnyttelsen som rapporteres av "filesys show space" (df). Siden disse to verdiene ikke samsvarer, kan de se forskjellen som "manglende eller ikke gjort rede for plass" ...
Instructions
Summen av størrelsen etter komprimering av alle filer rapportert av "sfs_dump" vil samsvare med den totale plassutnyttelsen bare hvis ingen slettinger noen gang har blitt utført på filsystemet. Dette er aldri tilfelle på en produksjons-DDR, så å bruke "sfs_dump" for å ta hensyn til gjeldende plassutnyttelse er en feilslutning. Vi vil illustrere dette med et eksempel nedenfor.
ILLUSTRASJON:
Dette kan lett sees med et enkelt tre-trinns eksempel:
- Jeg sikkerhetskopierer en fil (file1) som er 10G. Si at dette er en helt ny boks og ingenting å de-duplisere med. Etterkompresjonsstørrelsen er dermed også rundt 10G.
# sfs_dump /data/col1/test/ /data/col1/test/file1: 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-modus (102 %): 02000100644
Som vist ovenfor er postkompresjonsstørrelsen 10G.
II. Deretter sikkerhetskopierer jeg en annen 10G-fil (fil2). Dette er veldig likt eller det samme som fil1.
# sfs_dump /data/col1/test /data/col1/test/file1: 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-modus (102 %): 02000100644 /data/col1/test/file2: 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%) modus: 02000100644
Som vist ovenfor tok file2 ingen ekstra plass da den de-dupliserte fullstendig med file1.
III. Nå sletter jeg File1 og kjører "sfs_dump" på mtree igjen.
# sfs_dump /data/col1/test /data/col1/test/file2: 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%) modus: 02000100644
Basert på ovenstående kan kunden forvente at det ikke brukes plass på filsystemet. Den eneste filen i mtree tar opp 0 byte etter komprimert (Summation av alle filer rapportert av sfs_dump er 0 byte). Men dette er en feilslutning. Plassutnyttelsen på systemet er faktisk 10G og reflekteres nøyaktig av df .
Dette er fordi File2 refererer til alle segmenter opprinnelig skrevet av File1. Slettingen av File1 frigjorde ingenting. "sfs_dump" viser ikke den opprinnelige Fil1 fordi den er slettet.
# df Active Tier: Ressursstørrelse GiB brukt GiB Benyttede GiB Use% Cleanable GiB * ---------------- -------- -------- --------- ---- -------------- /data: pre-comp - 10.0 - - - /data: post-comp 129479.5 10.7 129468.8 0% 10.2