Data Domain Software : Discrepantie tussen het gebruik gerapporteerd door "filesys show space (df)" en sfs_dump totalen
Summary: Sommige klanten tellen de "post-lc-size" (post-compressiegrootte) van alle bestanden die door "sfs_dump" worden gerapporteerd bij elkaar op en verwachten dat deze overeenkomt met het ruimtegebruik dat wordt gerapporteerd door "filesys show space" (df). Omdat deze twee waarden niet overeenkomen, kunnen ze het verschil zien als 'ontbrekende of niet-vermelde ruimte' ...
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
Het doel van "sfs_dump" (of filesys tonen compressie) is om een idee te krijgen van de compressie die voor een bestand wordt bereikt op het moment van opname. Het is niet de bedoeling dat het de totale gebruikte ruimte weergeeft.
De som van de post-compressiegrootte van alle bestanden die door "sfs_dump" worden gerapporteerd, komt alleen overeen met het totale ruimtegebruik als er nooit verwijderingen zijn uitgevoerd op het bestandssysteem. Dit is nooit het geval bij een productie-DDR, dus het gebruik van "sfs_dump" om rekening te houden met het huidige ruimtegebruik is een misvatting. We zullen dit hieronder illustreren met een voorbeeld.
ILLUSTRATIE:
Dit is gemakkelijk te zien aan de hand van een eenvoudig voorbeeld in drie stappen:
Zoals hierboven te zien is, is de postcompressiegrootte 10G.
II. Vervolgens maak ik een back-up van nog een 10G-bestand (file2). Dit lijkt erg op of is hetzelfde als bestand1.
Zoals hierboven te zien is, nam file2 geen extra ruimte in beslag omdat het volledig werd gededupliceerd met file1.
III. Nu verwijder ik File1 en voer ik "sfs_dump" opnieuw uit op de mtree.
Op basis van het bovenstaande mag de klant verwachten dat er geen ruimte op het bestandssysteem in beslag wordt genomen. Het enige bestand in de mtree neemt 0 bytes post-gecomprimeerd in beslag (de som van alle bestanden gerapporteerd door sfs_dump is 0 bytes). Maar dit is een misvatting. Het ruimtegebruik op het systeem is eigenlijk 10G en wordt nauwkeurig weergegeven door df.
Dit komt omdat File2 verwijst naar alle segmenten die oorspronkelijk door File1 zijn geschreven. Het verwijderen van File1 maakte niets vrij. "sfs_dump" toont niet het oorspronkelijke bestand1 omdat het is verwijderd.
De som van de post-compressiegrootte van alle bestanden die door "sfs_dump" worden gerapporteerd, komt alleen overeen met het totale ruimtegebruik als er nooit verwijderingen zijn uitgevoerd op het bestandssysteem. Dit is nooit het geval bij een productie-DDR, dus het gebruik van "sfs_dump" om rekening te houden met het huidige ruimtegebruik is een misvatting. We zullen dit hieronder illustreren met een voorbeeld.
ILLUSTRATIE:
Dit is gemakkelijk te zien aan de hand van een eenvoudig voorbeeld in drie stappen:
- Ik maak een back-up van een bestand (bestand1) dat 10G is. Stel dat dit een gloednieuwe doos is en niets om mee te dedupliceren. De post-compressiegrootte is dus ook rond de 10G.
# sfs_dump /data/col1/test/ /data/col1/test/file1: mtime: 1503023531690895000 fileid: 18 Grootte: 10736790004 type: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 0 (0%) pre_lc_size: 10772785048 post_lc_size: 10942680452 (102%-modus): 02000100644
Zoals hierboven te zien is, is de postcompressiegrootte 10G.
II. Vervolgens maak ik een back-up van nog een 10G-bestand (file2). Dit lijkt erg op of is hetzelfde als bestand1.
# sfs_dump /data/col1/test /data/col1/test/file1: mtime: 1503023531690895000 fileid: 18 Grootte: 10736790004 type: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 0 (0%) pre_lc_size: 10772785048 post_lc_size: 10942680452 (102%-modus): 02000100644 /data/col1/test/file2: mtime: 1503023531690895000 fileid: 19 Grootte: 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
Zoals hierboven te zien is, nam file2 geen extra ruimte in beslag omdat het volledig werd gededupliceerd met file1.
III. Nu verwijder ik File1 en voer ik "sfs_dump" opnieuw uit op de mtree.
# sfs_dump /data/col1/test /data/col1/test/file2: mtime: 1503023531690895000 fileid: 19 Grootte: 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
Op basis van het bovenstaande mag de klant verwachten dat er geen ruimte op het bestandssysteem in beslag wordt genomen. Het enige bestand in de mtree neemt 0 bytes post-gecomprimeerd in beslag (de som van alle bestanden gerapporteerd door sfs_dump is 0 bytes). Maar dit is een misvatting. Het ruimtegebruik op het systeem is eigenlijk 10G en wordt nauwkeurig weergegeven door df.
Dit komt omdat File2 verwijst naar alle segmenten die oorspronkelijk door File1 zijn geschreven. Het verwijderen van File1 maakte niets vrij. "sfs_dump" toont niet het oorspronkelijke bestand1 omdat het is verwijderd.
# df Active Tier: Resourcegrootte GiB gebruikt GiB beschikbaar GiB Use% wisbare 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.