Wat is een goede block size bij het kopiëren van de ene harde schijf naar de andere?

Bedankt voor je antwoord. Ik ben het echter niet eens met je opmerking dat je een stuk mist aan het einde van de schijf. dd is in staat delen van een blok te kopiëren. Als dd klaar is, staat er iets in de trant van "12345+321 blocks copied". Dat betekent dat hij 12345 hele blokken, plus een "restje" van 321 bytes heeft gekopieerd. De gzip tussen de "lees-dd" en de "schrijf-dd" in is een geod idee. Maar bij mij gaat dat niet werken. Wat ik er namelijk niet bij had verteld, is dat mijn interne schijven versleuteld zijn met TrueCrypt. Ze bestaan dus vrijwel geheel uit oncomprimeerbare gegevens. Wat ik uit je antwoord haal, is dat mijn beginkeuze (eigenlijk: gok) van bs=2M volgens jou een prima startpunt is. Ik kan dus hiermee beginnen, en dan gewoon de benodigde tijd opmeten (commando "time"). Bij de volgende back-up kan ik hetzelfde doen met een bs=1M, de daaropvolgende back-up een bs=4M, dan bs=512k, dan bs=8M, en dan zie ik vanzelf wat het optimum is en of het eigenlijk iets uitmaakt. Ik heb nu in ieder geval een startpunt (2M of 1M), waarvoor dank.

Dat 'stuk missen' is misschien paranoia van me, en/of omdat dd ooit wel echt per block ging. Compressie gaat inderdaad zo niet lukken. Tenzij je natuurlijk leest van de unencrypted block device (ken truecrypt niet), gzip en on the fly herencryptie er achteraan. Om het op te meten zou je ook een loopje kunnen maken die verschillende sizes uitprobeert. Je hoeft niet de hele schijf te doen. Iets van 4G is genoeg om te kunnen meten. for size in 32k 64k 128k 256k 512k 1M 2M 4M 8M 16M
do
dd... $size...
done

Of 4G genoeg is voor een test, durf ik niet te zeggen. Ik heb bij de interne harde schijf al gemerkt dat de binnenkant aanzienlijk (en dan bedoel ik echt aanzienlijk) sneller is dan de buitenkant. Als het snelheidsverloop afhankelijk is van de block size, zou je dus overal een dd-testje moeten doen. Dan zou het dus iets moeten worden als      for size in 32k 64k 128k 256k 512k 1M 2M 4M 8M 16M
     do
          dd ... $size ...
          dd ... skip=... seek=... $size ...
          dd ... skip=... seek=... $size ...
          dd ... skip=... seek=... $size ...
          dd ... skip=... seek=... $size ...
          dd ... skip=... seek=... $size ...
     done Hierbij worden de skips en seeks zo gekozen dat je een stukje kopieert rond 0%, 20%, 40%, 60%, 80% en 100% van de schijf. Oh ja, en dan natuurlijk nog een "time" om al die dd's heen.

Ik denk dat het snelheidsverschil komt doordat de data nog in de disk block cache zat. Om goed te kunnen meten moet die geen of andere data bevatten, zodat hij wel van physical disk moet lezen. Tussen twee metingen dus je RAM vol lezen met data van een andere schijf. De cylinders aan de buitenkant moeten sneller zijn dan die aan de binnenkant. De schijven draaien op een vast toerental, anders dan bij cd's. De density is overal ongeveer gelijk. Aan de buitenkant zitten alleen meer sectoren, dus zal bij een rotatie meer data vrijkomen.

Ik vrees dat ik "buitenkant" en "binnenkant" heb verwisseld... Wat ik bedoel (en zeker weet) is dat gegevens op de lagere sectornummers sneller toegankelijk zijn dan gegevens op de hogere sectornummers. Dit geldt zowel voor lezen als voor schrijven.

Omdat de seek-time van lage sectoren kleiner is misschien? Als je het meet ben ik benieuwd naar de uitkomsten!

Ik zit het net even te proberen. /dev/sda is de interne harde schijf. Er is geen enkel ander proces actief op de harde schijf, alles draait van DVD en RAM-schijf. Commando:
dd if=/dev/sda of=/dev/null bs=2M skip=1000 count=1000 Resultaat:
1000+0 records in
1000+0 records out
2097152000 bytes (2.1 GB) copied, 11.5979 s, 181 MB/s Hetzelfde commando nog twee keer geprobeerd. Hetzelfde resultaat, maar nu resp. 11.6088 s en 11.5959 s. Vervolgens hetzelfde commando gegeven, maar nu met een hogere skip-waarde zodat er van de "achterkant" van de schijf wordt gelezen. Commando:
dd if=/dev/sda of=/dev/null bs=2M skip=1400000 count=1000 Ik heb ook dit drie keer gedaan; resultaat: 20.9293 s, 20.9309 s en 20.9008 s. In plaats van 181 MB/s geeft hij nu een snelheid aan van 100 MB/s. Je ziet: voor lage sectornummers is de schijf echt aanzienlijk sneller dan voor hoge sectornummers.

Ik heb ook meteen maar even getest wat dd doet met "halve blokken". Cryofiel:~# dd if=/dev/zero of=Alpha bs=14 count=3
3+0 records in
3+0 records out
42 bytes (42 B) copied, 3.953e-05 s, 1.1 MB/s Cryofiel:~# dd if=Alpha of=Omega bs=9
4+1 records in
4+1 records out
42 bytes (42 B) copied, 5.4546e-05 s, 770 kB/s Cryofiel:~# ll
total 8
-rw-r--r-- 1 Cryofiel Cryofiel 42 Nov 30 22:30 Alpha
-rw-r--r-- 1 Cryofiel Cryofiel 42 Nov 30 22:31 Omega De eerste dd creeert een bestand Alpha van 42 bytes, middels 3 blokken van elk 14 bytes. Hij geeft dan ook aan dat hij "3+0" records heeft verwerkt. De tweede dd kopieert dat bestand in blokken van 9 bytes. Dat zijn 4 hele blokken van 9 bytes, plus een "half blok" van 6 bytes. Hij geeft dan ook aan dat hij "4+1" records heeft verwerkt. De ll laat zien dat toch netjes het hele bestand is gekopieerd. Het "halve blok" aan het einde is dus keurig verwerkt.

Wat voor geweldige schijf heb je? Ik vind 181MB/sec heel erg veel voor een (hard)disk. 100 lijkt me veel realistischer. Ik heb het ook even geprobeerd, en bij mij maakt het niet uit waar op de schijf ik lees. Dat dd ook halve blokken doet, is mooi meegenomen. Maar hij zegt +1 records, in plaats van het aantal bytes, dus dat vond ik vreemd. Maar het werkt dus. # dd if=/dev/urandom of=Alpha bs=14 count=3
3+0 records in
3+0 records out
42 bytes (42 B) copied, 0.00177315 s, 23.7 kB/s
# dd if=Alpha of=Omega bs=9
4+1 records in
4+1 records out
42 bytes (42 B) copied, 0.00213307 s, 19.7 kB/s
# cmp Alpha Omega && echo OK
OK

SATA3 en 10000 rpm zorgen voor de snelheid. Die "+1" is het aantal "partial input blocks" resp. het aantal "partial output blocks". Hij telt dus geen bytes, maar het aantal blokken dat kleiner is dan bs (of ibs c.q. obs). Zie http://pubs.opengroup.org/onlinepubs/9699919799/utilities/dd.html onder het kopje STDERR. Ik zie dat jouw test grondiger is dan de mijne, met urandom en cmp. Hoe dan ook: QED.