Data Domain-software: Sådan forstår du uoverensstemmelser mellem brug rapporteret af Df og Sfs_dump totaler

Summary: Nogle kunder tilføjer "post-lc-størrelse" (postkomprimeringsstørrelse) for alle filer, der rapporteres af "sfs_dump." Og de forventer, at det svarer til pladsudnyttelsen rapporteret af "filesys show space" (df). Da disse to værdier ikke stemmer overens, kan de se forskellen som "manglende eller ikke-registreret 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.
Check out other resources

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 illustrerer dette med et eksempel nedenfor.

ILLUSTRATION:
Dette kan ses med et simpelt tretrinseksempel:

  1. Jeg sikkerhedskopierer en fil (fil1), der er 10G. Sig, at dette er en helt ny boks og intet at deduplikere med. Postkomprimeringsstørrelsen er derfor også omkring 10G.

    # 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

    Som det ses ovenfor, er postkomprimeringsstørrelsen 10G.

  2. Dernæst sikkerhedskopierer jeg en anden 10G-fil (fil2) Dette ligner eller er det samme som fil1.

    # 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

    Som det ses ovenfor, tog file2 ingen ekstra plads, da den deduplikeret fuldstændigt med file1.

  3. Nu sletter jeg File1 og kører "sfs_dump" på mtree igen.

    # 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

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 df afspejler det nøjagtigt.

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 File1, fordi den er blevet slettet.

# 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

 

Affected Products

DD OS 5.5, DD OS 5.6, DD OS 6.0, DD OS 6.1, DD OS Previous Versions

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: 22 Jan 2026
Version:  4
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.