Data Domain Virtual Edition: Förklaring av användning av datadiskutrymme på Data Domain Virtual Edition (DDVE)
Summary: Förklaring av användning av datadiskutrymme på Data Domain Virtual Edition (DDVE)
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.
Symptoms
Data Domain Virtual Edition (DDVE) är en ny produkt som möjliggör driftsättning av Data Domain Restorer (DDR) i en virtuell miljö. När distributionen har slutförts är det nödvändigt att tillhandahålla datadiskar för användning av DDFS-filsystemet i DDVE. Den här artikeln beskriver hur fysiskt utrymme på dessa datadiskar används och varför det användbara utrymmet i DDFS-filsystemet kan vara betydligt lägre än den kombinerade storleken på alla datadiskar
Resolution
När du lägger till datadiskar i en instans av DDVE måste vissa kapacitetsregler följas:
– Den första datadisken som läggs till måste vara minst 200 GB stor
. – Alla efterföljande datadiskar måste vara minst 100 GB stora
Anledningen till att den första disken måste vara minst 200 GB stor är att det finns betydande omkostnader på den här disken enligt beskrivningen nedan.
Anta att en datadisk på 200 Gb presenteras för DDVE, läggs till i den aktiva nivån och används för att skapa en instans av DDFS-filsystemet. Den fysiska disken används på följande sätt:
Inledningsvis partitioneras disken så att sektor 5 används för datalagring och sektor 6 används för ext3-filsystem:
Modell: Okänd (okänd)
Disk /dev/dm-4: 200 GiB
Sektorstorlek (logisk/fysisk): 512B/512B
Partitionstabell
: gpt-nummer
Start Slutstorlek Filsystemnamn Flaggor 1 0,00GiB 0,00GiB 0,00GiBprimär
2 0,00GiB 0,00GiB 0,00GiBprimär
3 0,00GiB 0,01GiB 0,01GiB primär
4 0,01GiB 0,01GiB 0,00GiB primär
5 0,01GiB 193GiB 193GiB primär <=== Används för datalagring
6 193GiB 200GiB 6,77GiB primär <=== Används för ext3
Som ett resultat av detta kommer ~193 GB diskutrymme (sektor 5) att ges till RAID-drivrutinen för användning.
Observera dock att DDVE använder ett koncept för RAID på LUN (ROL) för att skydda mot vissa typer av datakorruption (till exempel datakorruption som inte kan upptäckas/repareras av det underliggande lagringsdisksystemet). ROL reserverar cirka 5,6 % av utrymmet i sektor 5 för paritetsinformation. Det innebär att RAID endast gör ~182,3 GB tillgängligt för användning av DDFS (som visas nedan – observera att varje sektor är 512 byte stor):
Array [ppart2] (aktiv): [RAID-typ 106] [(0x1, 0x30) alternativ] [NVR: N/N] [4608 KB stripe] [382362624 sektorer] [382362624 totalt antal sektorer]
[DM-4P5]
Det ~182,3 Gb utrymme som ges till DDFS är uppdelat i block på 1075838976 byte - som ett resultat kan vi skapa 181 sådana block. Blocken allokeras sedan till olika filsystem på högre nivå i DDFS efter behov. Observera att när du skapar en ny instans av DDFS måste en betydande mängd utrymme allokeras för metadata som index/sammanfattningsvektor/CP meta/reserverade blockfilsystem:
FAST ANTAL BLOCKSTORLEKAR
STORLEK BLOCKSTORLEK NAMN
Ja 194726854656 181 1075838976 /.. /vpart:/vol2/col1
Ja 194726854656 181 1075838976 /.. /vpart:/vol2/col1/cp1
nr 37654364160 21 1075838976 /.. /vpart:/vol2/col1/cp1/cset
nr 65626177536 61 1075838976 /.. /vpart:/vol2/col1/cp1/full_indices
nr 22592618496 21 1075838976 /.. /vpart:/vol2/col1/cp1/partial_indices
nr 1075838976 1 1075838976 /.. /vpart:/vol2/col1/cp1/summary.0
No 1075838976 1 1075838976 /.. /vpart:/vol2/col1/cp1/summary.1
No 1075838976 1 1075838976 /.. /vpart:/vol2/col1/cp_meta
nr 10758389760 10 1075838976 /.. /vpart:/vol2/reserved_blocks
Observera att allt annat än behållaruppsättningen (CSET - där användardata lagras) förbrukar 95 * 1075838976 byteblock. Som ett resultat av detta finns det 86 block kvar för potentiell användning av CSET. Observera att 86 * 1075838976 byte = ~86,2 Gb.
Inom CSET använder vi en mycket liten mängd utrymme för metadata och uppskattar sedan att vi kan använda alla återstående 1075838976 byte-block på systemet för att skapa 4,5 Mb-containrar. Om vi kontrollerar CSET-metadata ser vi:cm_attrs.psize=
4718592 <=== Varje behållare är 4.5Mb
...
cm_attrs.max_containers=17403 <=== Maximalt antal "användbara" behållare
...
cm_attrs.reserved_containers=2176 <=== Reserverade behållare för interna åtgärder
Det totala antalet behållare som kan skapas i CSET är 17403 + 2176 = 19579
Varje behållare är 4,5 MB stor, så 19579 behållare motsvarar 86,0 Gb diskutrymme
Observera dock att reserverade behållare endast är avsedda för internt bruk (genom åtgärder som t.ex. rensning) och därför inte beaktas när filsystemets användbara storlek visas för användarna. På grund av detta är den "användbara" storleken på DDFS-filsystemet 17403 * 4,5 Mb = ~76,5 Gb
Av den anledningen, om en användare kör "filesys show space" efter att ha lagt till en enda disk på 200 Gb och skapat en instans av DDFS, kommer de att se att DDFS-filsystemet bara är 76,5 Gb i storlek:
Active Tier:
Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 9,0 - - -
/data: post-comp 76,5 15,0 61,4 20% 1,1
/ddvar 49,2 1,3 45,4 3% -
/ddvar/core 158,5 0,7 149,7 0% -
---------------- -------- -------- --------- ---- --------------
Observera att omkostnaderna för efterföljande datadiskar är betydligt lägre:
- Efterföljande diskar innehåller inte ext3-filsystem
– DDFS-metadata finns redan på den första disken, så väldigt lite skapas på efterföljande diskar
Låt oss till exempel anta att vi lägger till en andra disk på 100 Gb och expanderar DDFS. På den här disken ges sektor 5 till RAID-drivrutinen (precis som på den första disken), men skiva 6, medan den fortfarande skapas, kommer endast att vara 4 Kb stor:
6 107 GB 107 GB 4096B primär
Det innebär att praktiskt taget hela den andra disken går till RAID (via skiva 5). RAID använder 5,6 % av det här utrymmet för ROL och presenterar sedan resten för DDFS – i följande exempel ges ~94,3 Gb av 100 Gb-disken till DDFS för användning:
Array [ppart3] (aktiv): [RAID-typ 106] [(0x1, 0x30) alternativ] [NVR:N/N] [4608 KB stripe] [197858304 sektorer] [197858304 totalt antal sektorer]
[dm-2p5]
Detta utrymme är uppdelat i 1075838976 byteblock - som ett resultat skapar systemet ytterligare 93 block för DDFS att använda:
FAST ANTAL BLOCKSTORLEK
STORLEK BLOCK STORLEK NAMN
Ja 294779879424 274 1075838976 /.. /vpart:/vol1/col1
Ja 294779879424 274 1075838976 /.. /vpart:/vol1/col1/cp1
nr 22592618496 21 1075838976 /.. /vpart:/vol1/col1/cp1/cset
nr 65626177536 61 1075838976 /.. /vpart:/vol1/col1/cp1/full_indices
nr 22592618496 21 1075838976 /.. /vpart:/vol1/col1/cp1/partial_indices
nr 1075838976 1 1075838976 /.. /vpart:/vol1/col1/cp1/summary.0
No 1075838976 1 1075838976 /.. /vpart:/vol1/col1/cp1/summary.1
No 2151677952 2 1075838976 /.. /vpart:/vol1/col1/cp_meta
nr 10758389760 10 1075838976 /.. /vpart:/vol1/reserved_blocks
Observera att eftersom alla metadatafilsystem redan har skapats på den första datadisken används endast ett enda block för metadata på den andra disken (via det cp_meta filsystemet). Resten av utrymmet görs tillgängligt för CSET och anses vara användbart för normala behållare:
cm_attrs.max_containers=38379
...
cm_attrs.reserved_containers=2176
Observera att 38379 * 4,5 Mb = ~168,7 Gb:
Resursstorlek GiB Använda GiB Avail GiB Use% Cleanable GiB
---------------- -------- -------- --------- ---- -------------
/data: pre-comp - 0,0 - - -
/data: post-comp 168,7 0,1 168,6 0% 0,0
/ddvar 49,2 0,5 46,2 1% -
/ddvar/kärna 158,5 0,3 150,1 0 % -
---------------- -------- -------- --------- ---- -------------
Detta visar att omkostnaderna är betydligt mindre på alla utom den första datadisken:
Från den första disken på 200 Gb fick DDFS 76,5 GB användbart utrymme
Från den andra datadisken på 100 Gb fick DDFS 92,2 GB användbart utrymme
Den här trenden fortsätter för alla efterföljande datadiskar.
Slutligen bör det noteras att metadata inom DDFS (t.ex. indexfilsystemen) inte är fasta i storlek. Beroende på systemets arbetsbelastning kan de behöva växa, vilket tar användbart utrymme från CSET. Om detta händer kommer den användbara storleken på CSET att minska. Detta är förväntat – den totala storleken på CSET (och storleken på DDFS-filsystemet enligt "filesys show space") bör inte betraktas som ett statiskt värde även om storleken på underliggande datadiskar inte ändras.
– Den första datadisken som läggs till måste vara minst 200 GB stor
. – Alla efterföljande datadiskar måste vara minst 100 GB stora
Anledningen till att den första disken måste vara minst 200 GB stor är att det finns betydande omkostnader på den här disken enligt beskrivningen nedan.
Anta att en datadisk på 200 Gb presenteras för DDVE, läggs till i den aktiva nivån och används för att skapa en instans av DDFS-filsystemet. Den fysiska disken används på följande sätt:
Inledningsvis partitioneras disken så att sektor 5 används för datalagring och sektor 6 används för ext3-filsystem:
Modell: Okänd (okänd)
Disk /dev/dm-4: 200 GiB
Sektorstorlek (logisk/fysisk): 512B/512B
Partitionstabell
: gpt-nummer
Start Slutstorlek Filsystemnamn Flaggor 1 0,00GiB 0,00GiB 0,00GiBprimär
2 0,00GiB 0,00GiB 0,00GiBprimär
3 0,00GiB 0,01GiB 0,01GiB primär
4 0,01GiB 0,01GiB 0,00GiB primär
5 0,01GiB 193GiB 193GiB primär <=== Används för datalagring
6 193GiB 200GiB 6,77GiB primär <=== Används för ext3
Som ett resultat av detta kommer ~193 GB diskutrymme (sektor 5) att ges till RAID-drivrutinen för användning.
Observera dock att DDVE använder ett koncept för RAID på LUN (ROL) för att skydda mot vissa typer av datakorruption (till exempel datakorruption som inte kan upptäckas/repareras av det underliggande lagringsdisksystemet). ROL reserverar cirka 5,6 % av utrymmet i sektor 5 för paritetsinformation. Det innebär att RAID endast gör ~182,3 GB tillgängligt för användning av DDFS (som visas nedan – observera att varje sektor är 512 byte stor):
Array [ppart2] (aktiv): [RAID-typ 106] [(0x1, 0x30) alternativ] [NVR: N/N] [4608 KB stripe] [382362624 sektorer] [382362624 totalt antal sektorer]
[DM-4P5]
Det ~182,3 Gb utrymme som ges till DDFS är uppdelat i block på 1075838976 byte - som ett resultat kan vi skapa 181 sådana block. Blocken allokeras sedan till olika filsystem på högre nivå i DDFS efter behov. Observera att när du skapar en ny instans av DDFS måste en betydande mängd utrymme allokeras för metadata som index/sammanfattningsvektor/CP meta/reserverade blockfilsystem:
FAST ANTAL BLOCKSTORLEKAR
STORLEK BLOCKSTORLEK NAMN
Ja 194726854656 181 1075838976 /.. /vpart:/vol2/col1
Ja 194726854656 181 1075838976 /.. /vpart:/vol2/col1/cp1
nr 37654364160 21 1075838976 /.. /vpart:/vol2/col1/cp1/cset
nr 65626177536 61 1075838976 /.. /vpart:/vol2/col1/cp1/full_indices
nr 22592618496 21 1075838976 /.. /vpart:/vol2/col1/cp1/partial_indices
nr 1075838976 1 1075838976 /.. /vpart:/vol2/col1/cp1/summary.0
No 1075838976 1 1075838976 /.. /vpart:/vol2/col1/cp1/summary.1
No 1075838976 1 1075838976 /.. /vpart:/vol2/col1/cp_meta
nr 10758389760 10 1075838976 /.. /vpart:/vol2/reserved_blocks
Observera att allt annat än behållaruppsättningen (CSET - där användardata lagras) förbrukar 95 * 1075838976 byteblock. Som ett resultat av detta finns det 86 block kvar för potentiell användning av CSET. Observera att 86 * 1075838976 byte = ~86,2 Gb.
Inom CSET använder vi en mycket liten mängd utrymme för metadata och uppskattar sedan att vi kan använda alla återstående 1075838976 byte-block på systemet för att skapa 4,5 Mb-containrar. Om vi kontrollerar CSET-metadata ser vi:cm_attrs.psize=
4718592 <=== Varje behållare är 4.5Mb
...
cm_attrs.max_containers=17403 <=== Maximalt antal "användbara" behållare
...
cm_attrs.reserved_containers=2176 <=== Reserverade behållare för interna åtgärder
Det totala antalet behållare som kan skapas i CSET är 17403 + 2176 = 19579
Varje behållare är 4,5 MB stor, så 19579 behållare motsvarar 86,0 Gb diskutrymme
Observera dock att reserverade behållare endast är avsedda för internt bruk (genom åtgärder som t.ex. rensning) och därför inte beaktas när filsystemets användbara storlek visas för användarna. På grund av detta är den "användbara" storleken på DDFS-filsystemet 17403 * 4,5 Mb = ~76,5 Gb
Av den anledningen, om en användare kör "filesys show space" efter att ha lagt till en enda disk på 200 Gb och skapat en instans av DDFS, kommer de att se att DDFS-filsystemet bara är 76,5 Gb i storlek:
Active Tier:
Resource Size GiB Used GiB Avail GiB Use% Cleanable GiB*
---------------- -------- -------- --------- ---- --------------
/data: pre-comp - 9,0 - - -
/data: post-comp 76,5 15,0 61,4 20% 1,1
/ddvar 49,2 1,3 45,4 3% -
/ddvar/core 158,5 0,7 149,7 0% -
---------------- -------- -------- --------- ---- --------------
Observera att omkostnaderna för efterföljande datadiskar är betydligt lägre:
- Efterföljande diskar innehåller inte ext3-filsystem
– DDFS-metadata finns redan på den första disken, så väldigt lite skapas på efterföljande diskar
Låt oss till exempel anta att vi lägger till en andra disk på 100 Gb och expanderar DDFS. På den här disken ges sektor 5 till RAID-drivrutinen (precis som på den första disken), men skiva 6, medan den fortfarande skapas, kommer endast att vara 4 Kb stor:
6 107 GB 107 GB 4096B primär
Det innebär att praktiskt taget hela den andra disken går till RAID (via skiva 5). RAID använder 5,6 % av det här utrymmet för ROL och presenterar sedan resten för DDFS – i följande exempel ges ~94,3 Gb av 100 Gb-disken till DDFS för användning:
Array [ppart3] (aktiv): [RAID-typ 106] [(0x1, 0x30) alternativ] [NVR:N/N] [4608 KB stripe] [197858304 sektorer] [197858304 totalt antal sektorer]
[dm-2p5]
Detta utrymme är uppdelat i 1075838976 byteblock - som ett resultat skapar systemet ytterligare 93 block för DDFS att använda:
FAST ANTAL BLOCKSTORLEK
STORLEK BLOCK STORLEK NAMN
Ja 294779879424 274 1075838976 /.. /vpart:/vol1/col1
Ja 294779879424 274 1075838976 /.. /vpart:/vol1/col1/cp1
nr 22592618496 21 1075838976 /.. /vpart:/vol1/col1/cp1/cset
nr 65626177536 61 1075838976 /.. /vpart:/vol1/col1/cp1/full_indices
nr 22592618496 21 1075838976 /.. /vpart:/vol1/col1/cp1/partial_indices
nr 1075838976 1 1075838976 /.. /vpart:/vol1/col1/cp1/summary.0
No 1075838976 1 1075838976 /.. /vpart:/vol1/col1/cp1/summary.1
No 2151677952 2 1075838976 /.. /vpart:/vol1/col1/cp_meta
nr 10758389760 10 1075838976 /.. /vpart:/vol1/reserved_blocks
Observera att eftersom alla metadatafilsystem redan har skapats på den första datadisken används endast ett enda block för metadata på den andra disken (via det cp_meta filsystemet). Resten av utrymmet görs tillgängligt för CSET och anses vara användbart för normala behållare:
cm_attrs.max_containers=38379
...
cm_attrs.reserved_containers=2176
Observera att 38379 * 4,5 Mb = ~168,7 Gb:
Resursstorlek GiB Använda GiB Avail GiB Use% Cleanable GiB
---------------- -------- -------- --------- ---- -------------
/data: pre-comp - 0,0 - - -
/data: post-comp 168,7 0,1 168,6 0% 0,0
/ddvar 49,2 0,5 46,2 1% -
/ddvar/kärna 158,5 0,3 150,1 0 % -
---------------- -------- -------- --------- ---- -------------
Detta visar att omkostnaderna är betydligt mindre på alla utom den första datadisken:
Från den första disken på 200 Gb fick DDFS 76,5 GB användbart utrymme
Från den andra datadisken på 100 Gb fick DDFS 92,2 GB användbart utrymme
Den här trenden fortsätter för alla efterföljande datadiskar.
Slutligen bör det noteras att metadata inom DDFS (t.ex. indexfilsystemen) inte är fasta i storlek. Beroende på systemets arbetsbelastning kan de behöva växa, vilket tar användbart utrymme från CSET. Om detta händer kommer den användbara storleken på CSET att minska. Detta är förväntat – den totala storleken på CSET (och storleken på DDFS-filsystemet enligt "filesys show space") bör inte betraktas som ett statiskt värde även om storleken på underliggande datadiskar inte ändras.
Additional Information
Observera att informationen i den här artikeln gäller från och med DDOS 5.7.30.0 och kan komma att ändras i senare versioner.
Affected Products
Data Domain Virtual EditionProducts
Data Domain, Data Domain Virtual EditionArticle Properties
Article Number: 000059680
Article Type: Solution
Last Modified: 05 Sep 2025
Version: 3
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.