dd | gzip > img.gz is enorm sloom?

[IStealYourGun]

Ik heb een beetje schrik dat ik nu een domme vraag ga stellen, maar ik kan nergens echt een antwoord vinden. Ik ben aan de hand van live disk bezig een interne HDD aan het backupen naar een externe HDD met het dd commando en een BS van 2MB. Vervolgens pipe ik alles nog eens door gzip. Dus:

code:

dd if=/dev/sda bs=2M | gzip > img.gz

Alleen doet dit systeem er nu al meer dan 3 dagen over voor een HDD van 500GB te backupen en ik heb het gevoel dat het steeds trager gaat, is dit normaal?

[FitzJac]

code:

 dd if=/bla/bla/bla of=/bla/bla/bla bs=een/extra/optie(hoeft niet persé) | pijpen maakt me niet uit:)

maw, je moet wel een "of", cq "output file" opgeven. Waarschijnlijk wordt nu alles naar je geheugen geschreven

[ Voor 15% gewijzigd door FitzJac op 17-06-2013 13:17 ]

[johnkeates]

Tsja.. dat kan diverse redenen hebben. Wat zegt top? Alle cores bezet met gz? En anders iostat of een vergelijkbaar tooltje, ergens anders een bottleneck? en als je het zonder gz doet?

[Z-Dragon]

FitzJac schreef op maandag 17 juni 2013 @ 13:13:

code:

 dd if=/bla/bla/bla of=/bla/bla/bla bs=een/extra/optie(hoeft niet persé) | pijpen maakt me niet uit:)

maw, je moet wel een "of", cq "output file" opgeven. Waarschijnlijk wordt nu alles naar je geheugen geschreven

Als je wilt gzippen kun je natuurlijk niet daarvoor al naar een bestand schrijven in plaats van stdout, want dan bereikt de data gzip nooit. Wat hij doet is dus correct.

Weet je wel zeker dat die harde schijf in orde is? Anders moet je eens ddrescue of dd_rescue gebruiken, welke om kunnen gaan met leesfouten.

[ Voor 4% gewijzigd door Z-Dragon op 17-06-2013 13:24 ]

[FitzJac]

Z-Dragon schreef op maandag 17 juni 2013 @ 13:21:
[...]
Als je wilt gzippen kun je natuurlijk niet daarvoor al naar een bestand schrijven. Wat hij doet is dus correct.

Weet je wel zeker dat die harde schijf in orde is? Anders moet je eens ddrescue of dd_rescue gebruiken, welke om kunnen gaan met leesfouten.

Daar heb je gelijk in maar dan moet 'ie de -c flag gebruiken icm gzip.

[Wolfboy]

Eventueel kan je pv gebruiken om te zien hoe snel dd z'n data doorgeeft.

[FitzJac]

Toch is dit denk ik dé manier:

code:

gzip -c /dev/sdaX >imagefile.gz

En de Arch-wiki vertrouw ik ook altijd: https://wiki.archlinux.or...oning_an_entire_hard_disk

[ Voor 44% gewijzigd door FitzJac op 17-06-2013 13:35 ]

[IStealYourGun]

De -c ben ik inderdaad vergeten, maar op eerste zicht lijkt dit geen problemen te geven aangezien er wel degelijk een compressed file wordt aangemaakt.

Het kan misschien wel aan diskerrors liggen. De status van de HDD is mij totaal onbekend, behalve dat ze vrij vol is, maar wanneer ik eerst probeerde met bzip2 dan kreeg ik wel foutmeldingen error code -3.

Maar het is dus wel degelijk abnormaal gedrag?

[FitzJac]

3 dagen lijkt mij idd wat lang, maar aan de andere kant zou dd moeten stoppen zodra er een error verschijnt (volgens de man pages).

[IStealYourGun]

Dat dacht ik dus ook. uit vorige ervaringen met dd weet ik dat hij inderdaad stopt bij een error, maar dit is de eerste maal dat ik hem naar een compressed image pipe. De cpu draait ondertussen mooi stabiel op 30%.

[Wolfboy]

IStealYourGun schreef op maandag 17 juni 2013 @ 13:46:
De -c ben ik inderdaad vergeten, maar op eerste zicht lijkt dit geen problemen te geven aangezien er wel degelijk een compressed file wordt aangemaakt.

Ook zonder de -c vlag zal je wel een bestand krijgen, alleen geen gzipped content.

Maar het is dus wel degelijk abnormaal gedrag?

Moeilijk te zeggen, maar ik zou persoonlijk iets als ddrescue of pv gebruiken zodat je in ieder geval een idee hebt van hoe ver je bent.

[blaataaps]

Je kunt met g(un)zip opvragen hoeveel ongecomprimeerde bytes er in je doelbestand zitten. Deze is niet supernauwkeurig als ik het me goed herinner, maar geeft wel een indiciatie (en je kunt hem ook nog uitpakken naar |wc -c of iets dergelijks, als je die I/O durft te gebruiken.

Overigens, als je dd een SIGUSR1 stuurt, dumpt ie op stderr statistieken over het aantal bytes e.d.

[IStealYourGun]

Wolfboy schreef op maandag 17 juni 2013 @ 15:46:
[...]
Ook zonder de -c vlag zal je wel een bestand krijgen, alleen geen gzipped content.

Zeker?

code:

stijn@:~/gzip$ cat test.txt | gzip > test1.gz      
stijn@:~/gzip$ cat test.txt | gzip -c > test2.gz   
stijn@:~/gzip$ ll                                  
total 20                                                
drwxr-xr-x  2 stijn stijn 4096 2013-06-17 18:25 ./      
drwxr-xr-x 21 stijn stijn 4096 2013-06-17 18:24 ../     
-rw-r--r--  1 stijn stijn 1175 2013-06-17 18:24 test1.gz
-rw-r--r--  1 stijn stijn 1175 2013-06-17 18:25 test2.gz
-rw-r--r--  1 stijn stijn 2866 2013-06-17 18:23 test.txt

Ik geef hem nog een nachtje omdat hij al dik over de helft zit, daarna vuur ik gewoon Clonezilla op, zien of dat betere resultaten geeft.

[Wolfboy]

IStealYourGun schreef op maandag 17 juni 2013 @ 18:30:
[...]


Zeker?

Het hangt van de aanroep af. Zonder de -c zal gzip z'n input bestand compressen en daarna exiten. Aangezien je hierbij geen echt input bestand hebt zal gnu gzip misschien slim genoeg zijn. Ik weet dat op een aantal unix systemen dit niet werkt(e).

[H!GHGuY]

blaataaps schreef op maandag 17 juni 2013 @ 17:25:
Overigens, als je dd een SIGUSR1 stuurt, dumpt ie op stderr statistieken over het aantal bytes e.d.

Dit dus.
Krijg je mooi te zien hoeveel data dd nu al richting gzip gestuurd heeft en hoe snel hij dat gemiddeld doet.
Dan heb je meteen ook een idee hoe lang het nog zal duren.

[deadinspace]

IStealYourGun schreef op maandag 17 juni 2013 @ 12:48:

code:

dd if=/dev/sda bs=2M | gzip > img.gz

dd was hier (net als in heel veel andere situaties) niet nodig geweeest,

code:

gzip -c < /dev/sda > img.gz

had ook volstaan

Nu is dd wel handig omdat je dmv SIGUSR1 statistieken kunt opvragen, maar als je voortgang wil zien geef ik zelf sterk de voorkeur aan pv:

code:

pv -s465G /dev/sda | gzip -c > img.gz

Maargoed.

Alleen doet dit systeem er nu al meer dan 3 dagen over voor een HDD van 500GB te backupen en ik heb het gevoel dat het steeds trager gaat, is dit normaal?

Hangt er van af, maar dat lijkt me niet normaal nee. Mijn Core2duo server doet gzip < /dev/sda met ongeveer 30 MB/sec, wat een uurtje of 5 zou moeten kosten voor 500GB. Dus tenzij jouw CPU erg traag is lijkt het er mij zo snel op dat het een I/O probleem is met het lezen van je harddisk (of eventueel het wegschrijven van de compressed image). Het zou eventueel kunnen dat die harde schijf gaar is en dat Linux veel re-reads moet doen, controleer je logs eens (syslog, messages)?

Probeer verder eens uit te zoeken (bv met top of ps auxf) of je kunt achterhalen hoeveel CPU-tijd gzip al heeft gebruikt. 5 uur CPU-tijd op 3 dagen betekent dat gzip niet door heeft kunnen werken, vermoedelijk omdat I/O de bottleneck is. 3 dagen CPU-tijd op 3 dagen betekent dat gzip traag compresst (en de vraag is dan weer waarom dat is)...

FitzJac schreef op maandag 17 juni 2013 @ 13:13:

code:

 dd if=/bla/bla/bla of=/bla/bla/bla bs=een/extra/optie(hoeft niet persé) | pijpen maakt me niet uit:)

maw, je moet wel een "of", cq "output file" opgeven. Waarschijnlijk wordt nu alles naar je geheugen geschreven

Nee, als je geen output file opgeeft bij dd dan schrijft hij de output naar stdout. Sterker nog, als je een output file opgeeft heeft pipen geen nut meer

[Rainmaker]

Is gzip hier mogelijk de bottleneck? Standaard is gzip bij mijn weten single-threaded, en zal hij dus max 1 core bezet houden.

Een utility als pbzip2 kan wel multi-threaded alle cores bezet houden..

[Wolfboy]

Rainmaker schreef op dinsdag 18 juni 2013 @ 17:03:
Is gzip hier mogelijk de bottleneck? Standaard is gzip bij mijn weten single-threaded, en zal hij dus max 1 core bezet houden.

Een utility als pbzip2 kan wel multi-threaded alle cores bezet houden..

Dan moet het wel een bijzonder trage cpu zijn, dit haal ik op een Core 2 Duo in een virtuele machine (VMWare).

# cat /dev/zero | pv | gzip -c >| /dev/null
57GB 0:00:21 [77.8MB/s] [                                           <=>                                                             ]

[IStealYourGun]

Bedankt voor de informatie, hij was deze ochtend nog steeds bezig en aangezien er een deadline is heb ik hem maar afgesloten en clonezilla opgestart en die deed wat het moest doen. HDD is mooi gebackupt.

Dat je geen dd nodig hebt is nieuw voor mij en ga ik (proberen) te onthouden, net als het pv commando.

[H!GHGuY]

Wolfboy schreef op dinsdag 18 juni 2013 @ 17:16:
[...]
Dan moet het wel een bijzonder trage cpu zijn, dit haal ik op een Core 2 Duo in een virtuele machine (VMWare).

# cat /dev/zero | pv | gzip -c >| /dev/null
57GB 0:00:21 [77.8MB/s] [                                           <=>                                                             ]

Right... allemaal nullen zippen met 0 delay voor reads en dat vergelijken met het zippen van data die van een HDD komt.

[Kees]

Overigens kun je je dd process ook signalen met 'kill -USR1 $dd-process' dan geeft hij tussentijdse statistieken en kun je zien of hij wel iets doet.

[blaataaps]

Gamma

[Wolfboy]

H!GHGuY schreef op woensdag 19 juni 2013 @ 12:15:
[...]


Right... allemaal nullen zippen met 0 delay voor reads en dat vergelijken met het zippen van data die van een HDD komt.

Goed punt, daar had ik even geen rekening mee gehouden. Nullen zal vast een stuk sneller gaan.
Maar wat de delay te maken heeft met de snelheid van gzip begrijp ik even niet?

Hierbij dezelfde test met random data:

# dd if=/dev/random of=random bs=1M count=4096

# pv random | gzip -c  > /dev/null
65GiB 0:01:25 [31.9MiB/s] [=========================================================>                               ] 66% ETA 0:00:43

[H!GHGuY]

Wolfboy schreef op donderdag 20 juni 2013 @ 16:58:
[...]
Goed punt, daar had ik even geen rekening mee gehouden. Nullen zal vast een stuk sneller gaan.
Maar wat de delay te maken heeft met de snelheid van gzip begrijp ik even niet?

Hierbij dezelfde test met random data:

# dd if=/dev/random of=random bs=1M count=4096

# pv random | gzip -c  > /dev/null
65GiB 0:01:25 [31.9MiB/s] [=========================================================>                               ] 66% ETA 0:00:43

/dev/null lezen is gewoon wat memory vullen met 0-bytes. Delay is daarbij bijna nihil.
Wanneer je van een block-device leest, zit er nog een complete block-layer tussen en moet je wachten op de data die aangeleverd moet worden van je HDD. De delay die daarbij komt kijken is vele grootte-ordes groter dan gewoon wat memory nullifyen of zelfs random-data genereren.

[deadinspace]

H!GHGuY schreef op vrijdag 21 juni 2013 @ 12:07:
/dev/null lezen is gewoon wat memory vullen met 0-bytes. Delay is daarbij bijna nihil.
Wanneer je van een block-device leest, zit er nog een complete block-layer tussen en moet je wachten op de data die aangeleverd moet worden van je HDD. De delay die daarbij komt kijken is vele grootte-ordes groter dan gewoon wat memory nullifyen of zelfs random-data genereren.

Behalve dat Linux (en elk degelijk OS) aan readahead doet en dus "vooruit werkt" en de volgende blocks alvast in de achtergrond in de cache zet. Als je dan read() doet op het volgende block, dan komt die dus gewoon uit de cache en de enige delay is dus de overhead van de block cache (en die is niet zo heel groot).

Effectief betekent dat dat je gewoon op maximale snelheid van de harde schijf kunt lezen zonder je ergens druk over te maken en dat je dus alleen op de harde schijf hoeft te wachten als je die maximale snelheid bereikt hebt (dwz, als gzip niet de bottleneck is). Dus dat delay-verhaal klopt niet helemaal

[Wolfboy]

H!GHGuY schreef op vrijdag 21 juni 2013 @ 12:07:
[...]


/dev/null lezen is gewoon wat memory vullen met 0-bytes. Delay is daarbij bijna nihil.
Wanneer je van een block-device leest, zit er nog een complete block-layer tussen en moet je wachten op de data die aangeleverd moet worden van je HDD. De delay die daarbij komt kijken is vele grootte-ordes groter dan gewoon wat memory nullifyen of zelfs random-data genereren.

Ik weet wat delay is, ik zie alleen de relatie met gzip niet.

Specifieker, waarom zou gzip daardoor opeens trager worden? Afgezien van dat er een paar bufferes misschien even moeten wachten tot ze gevuld zijn (wat alleen in eerste instantie een minimale vertraging op zal leveren) blijft het voor de rest constant.

[ Voor 18% gewijzigd door Wolfboy op 22-06-2013 00:54 ]

[H!GHGuY]

Sure, Linux doet readahead. Maar de hoeveelheid code die aangeroepen wordt om naar de page cache te gaan is nog steeds een veelvoud van dat om een buffer leeg te maken. Zelfs al is je HDD niet de bottleneck, je zit nog steeds een pak CPU cycles op te soeperen door niet naar je block device te gaan.
Maw: vanuit het standpunt van gzip krijg je delays bij het binnenlezen van data.

En als je HDD wel een bottleneck is dan staat gzip gewoon uit z'n neus te eten en krijg je delays bij het binnenlezen van data.

Hoe dan ook: door niet van je HDD te lezen krijgt gzip delays bij het uitlezen van data - maw je vergelijkt appels met peren.

Linux zou bij wijze van optimalisatie bij het lezen van grote hoeveelheden data van /dev/zero kunnen kiezen om de zero page te mappen op de buffer. Maw, als de eerste blok unaligned is, die gewoon leegmaken. Dan de volgende blokken van PAGE_SIZE unmappen, de zero page mappen met COW, en uiteindelijk de unaligned data op het eind ook leeg maken.
De implementatie is echter dat het geheugen gewoon leeg gemaakt wordt.

[deadinspace]

H!GHGuY schreef op zaterdag 22 juni 2013 @ 09:58:
Sure, Linux doet readahead. Maar de hoeveelheid code die aangeroepen wordt om naar de page cache te gaan is nog steeds een veelvoud van dat om een buffer leeg te maken. Zelfs al is je HDD niet de bottleneck, je zit nog steeds een pak CPU cycles op te soeperen door niet naar je block device te gaan.

Kijk, natuurlijk is dat zo, maar de hoeveelheid CPU die dat kost is verwaarloosbaar ten opzichte van de hoeveelheid CPU die gzip gebruikt en dus niet erg relevant voor de test.

% dd if=/dev/zero of=test bs=1M count=1024; sync
% dd if=test bs=1M count=1024 > /dev/null
1073741824 bytes (1.1 GB) copied, 0.396746 s, 2.7 GB/s
% dd if=/dev/zero bs=1M count=1024 > /dev/null
1073741824 bytes (1.1 GB) copied, 0.146388 s, 7.3 GB/s

Jep, lezen uit /dev/zero is sneller dan lezen uit de block cache.

Maar als je gzip er tussen gooit verandert dat:

% for I in $(seq 1 5); do dd if=/dev/zero bs=1M count=1024 | gzip -c > /dev/null; done
1073741824 bytes (1.1 GB) copied, 11.3452 s, 94.6 MB/s
1073741824 bytes (1.1 GB) copied, 12.0902 s, 88.8 MB/s
1073741824 bytes (1.1 GB) copied, 12.0076 s, 89.4 MB/s
1073741824 bytes (1.1 GB) copied, 11.8522 s, 90.6 MB/s
1073741824 bytes (1.1 GB) copied, 11.5796 s, 92.7 MB/s

Gzippen direct vanuit /dev/zero: 91.2 MB/s gemiddeld, 94.6 MB/s max

% for I in $(seq 1 5); do dd if=test bs=1M count=1024 | gzip -c > /dev/null; done
1073741824 bytes (1.1 GB) copied, 12.6129 s, 85.1 MB/s
1073741824 bytes (1.1 GB) copied, 12.2719 s, 87.5 MB/s
1073741824 bytes (1.1 GB) copied, 11.4822 s, 93.5 MB/s
1073741824 bytes (1.1 GB) copied, 11.7863 s, 91.1 MB/s
1073741824 bytes (1.1 GB) copied, 11.1484 s, 96.3 MB/s

Gzippen vanuit de block cache: 90.7 MB/s gemiddeld, 96.3 MB/s max.

Dat zijn verwaarloosbare verschillen (zeker gezien de fluctuatie per run). En dat was mijn punt.

En als je HDD wel een bottleneck is dan staat gzip gewoon uit z'n neus te eten en krijg je delays bij het binnenlezen van data.

Uiteraard, maar de context van deze /dev/zero discussie was dat gzip (en dus CPU) de bottleneck was; zie de originele post waar je op reageerde.

[H!GHGuY]

deadinspace schreef op zaterdag 22 juni 2013 @ 13:06:
Dat zijn verwaarloosbare verschillen (zeker gezien de fluctuatie per run). En dat was mijn punt.

Afhankelijk van de hoeveelheid data is ~2% niet compleet verwaarloosbaar. Er worden geregeld kernel patches geapplied die zo'n snelheidswinst geven waar iedereen best blij mee is.

Trouwens moet je om je test representatiever te maken nog een
echo 3 > /proc/sys/vm/drop_caches
tussen elke run doen. Pas dan benchmark je het geheel met disk readahead erbij.

[deadinspace]

H!GHGuY schreef op zaterdag 22 juni 2013 @ 13:15:
Afhankelijk van de hoeveelheid data is ~2% niet compleet verwaarloosbaar.

Of 2% verwaarloosbaar is of niet hangt af van de situatie. Waar het hier om ging is dat het gzippen van de topicstarter trager dan 2 MB/s ging, terwijl Wolfboy met 32 MB/s /dev/random kan gzippen. Bij zulke getallen is 2% volstrekt irrelevant.

Trouwens moet je om je test representatiever te maken nog een
echo 3 > /proc/sys/vm/drop_caches
tussen elke run doen. Pas dan benchmark je het geheel met disk readahead erbij.

Jij je zin:

# for I in $(seq 1 5); do sync; echo 3 >! /proc/sys/vm/drop_caches; dd if=/dev/zero bs=1M count=1024 | gzip -c > /dev/null; done
1073741824 bytes (1.1 GB) copied, 13.3613 s, 80.4 MB/s
1073741824 bytes (1.1 GB) copied, 12.8997 s, 83.2 MB/s
1073741824 bytes (1.1 GB) copied, 12.7893 s, 84.0 MB/s
1073741824 bytes (1.1 GB) copied, 13.0651 s, 82.2 MB/s
1073741824 bytes (1.1 GB) copied, 13.297 s, 80.8 MB/s
# dd if=/dev/zero of=/dev/vdb bs=1M count=1024
# for I in $(seq 1 5); do sync; echo 3 >! /proc/sys/vm/drop_caches; sleep 2; dd if=/dev/vdb bs=1M count=1024 | gzip -c > /dev/null; done
1073741824 bytes (1.1 GB) copied, 13.8255 s, 77.7 MB/s
1073741824 bytes (1.1 GB) copied, 13.9227 s, 77.1 MB/s
1073741824 bytes (1.1 GB) copied, 14.0608 s, 76.4 MB/s
1073741824 bytes (1.1 GB) copied, 13.9181 s, 77.1 MB/s
1073741824 bytes (1.1 GB) copied, 13.6717 s, 78.5 MB/s

82.1 MB/s versus 77.4 MB/s. Ongeveer 5% trager van disk dus, nog steeds irrelevant hier.

Origineel schreef je:

H!GHGuY schreef op vrijdag 21 juni 2013 @ 12:07:
[...] Wanneer je van een block-device leest, zit er nog een complete block-layer tussen en moet je wachten op de data die aangeleverd moet worden van je HDD. De delay die daarbij komt kijken is vele grootte-ordes groter dan gewoon wat memory nullifyen of zelfs random-data genereren.

En dat is waar ik tegen protesteer, dat lezen van disk "vele grootte-ordes" trager is dan van /dev/null voor gzip in een CPU-limited scenario. Dat is gewoon niet zo; 5% is nog niet eens één orde-grootte.

[H!GHGuY]

deadinspace schreef op zaterdag 22 juni 2013 @ 15:30:
Of 2% verwaarloosbaar is of niet hangt af van de situatie. Waar het hier om ging is dat het gzippen van de topicstarter trager dan 2 MB/s ging, terwijl Wolfboy met 32 MB/s /dev/random kan gzippen. Bij zulke getallen is 2% volstrekt irrelevant.

Waar lees jij 2MB/s ? Ik zie enkel dat de TS een dd met blocksize van 2MB gebruikt.
Hij zei ook dat zijn CPU op 30% draait. Geen idee of dit een quad-core is die 25% gzip en 5% dd+overhead is of dat gzip gewoon te traag zijn data binnen krijgt en niet meer dan ~30% CPU kan gebruiken.

Jij je zin:

# for I in $(seq 1 5); do sync; echo 3 >! /proc/sys/vm/drop_caches; dd if=/dev/zero bs=1M count=1024 | gzip -c > /dev/null; done
1073741824 bytes (1.1 GB) copied, 13.3613 s, 80.4 MB/s
1073741824 bytes (1.1 GB) copied, 12.8997 s, 83.2 MB/s
1073741824 bytes (1.1 GB) copied, 12.7893 s, 84.0 MB/s
1073741824 bytes (1.1 GB) copied, 13.0651 s, 82.2 MB/s
1073741824 bytes (1.1 GB) copied, 13.297 s, 80.8 MB/s
# dd if=/dev/zero of=/dev/vdb bs=1M count=1024
# for I in $(seq 1 5); do sync; echo 3 >! /proc/sys/vm/drop_caches; sleep 2; dd if=/dev/vdb bs=1M count=1024 | gzip -c > /dev/null; done
1073741824 bytes (1.1 GB) copied, 13.8255 s, 77.7 MB/s
1073741824 bytes (1.1 GB) copied, 13.9227 s, 77.1 MB/s
1073741824 bytes (1.1 GB) copied, 14.0608 s, 76.4 MB/s
1073741824 bytes (1.1 GB) copied, 13.9181 s, 77.1 MB/s
1073741824 bytes (1.1 GB) copied, 13.6717 s, 78.5 MB/s

82.1 MB/s versus 77.4 MB/s. Ongeveer 5% trager van disk dus, nog steeds irrelevant hier.

Je ziet sowieso al dat je resultaten minder spreiding hebben. 5% is best significant. Ik zou meteen tekenen voor een kernel change die me 5% meer performance gaf.

Origineel schreef je:
[...]
En dat is waar ik tegen protesteer, dat lezen van disk "vele grootte-ordes" trager is dan van /dev/null voor gzip in een CPU-limited scenario. Dat is gewoon niet zo; 5% is nog niet eens één orde-grootte.

De TS heeft 30% CPU usage; tenzij het zoals hierboven vermeld een quad-core is, lijkt zijn workload niet CPU-limited.

[Mr.Gab]

Hallo IStealYourGun,

Ik weet niet of je er al uit ben met het kopiëren maar bij deze mijn input;

http://allgood38.github.i...d-pv-and-gzip-part-1.html

In bovenstaand artikel beschrijft Stephen Cripps zijn visie op het maken van een snapshot.

Misschien heb je er nog wat aan.
Hij spreekt ook over pigz (uitspraak pig-zee), dat programma kan gebruik maken van meerdere core's.
En dat is dan ter vervanging van gzip.

geluk.

Edit: ik lees net tussen de berichten in dat je al een deadline had op de 18de, ik laat mijn info nog wel staan mocht iemand er nog naar willen kijken en leren.

[ Voor 16% gewijzigd door Mr.Gab op 23-06-2013 23:40 ]

[Wolfboy]

Pigz is best interessant ja

Op mijn werkstation uitgevoerd dus niet vergelijkbaar met de eerdere resultaten kwa performance (32GB ram dus alles kwam hier uit de filesystem cache):

# pv random >| /dev/null
4GB 0:00:00 [7.21GB/s] [=================================>] 100%

# pv random | pigz -c >| /dev/null
63GB 0:00:14 [ 196MB/s] [====================>            ] 65% ETA 0:00:07

[ Voor 53% gewijzigd door Wolfboy op 24-06-2013 13:40 ]