Platten mit dd kopieren (was: Re: Exakte Partitionsgrößen auf 2 Rechnern)

> > Schicke mal bitte ein "fdisk -l /dev/hda" von beiden Systemen ... oder
> > halt von der Platte, auf denen die jeweiligen rootfs liegen.
> 
> Du vermutest dasselbe wie ich? Dass beide Systeme die Platten mit
> unterschiedlicher CHS-Translatio erkannt haben?

Irgendwas in dieser Richtung.
Wäre darüberhinaus wichtig zu wissen, welche Hersteller / Modelle es
sind (aus dmesg) und so weiter.


--> Platten einfach 1:1 kopieren.

Wenn es wirklich identische Platten sind, könnte ein Transfer mittels dd
für eine Bit-identische Kopie sorgen (da spart man sich alle Experimente
mit fdisk etc). 
Sind die Platten leicht unterschiedlich gross, dann kopiert man eben das
Abbild von der kleineren auf die größere und verliert die Kapazitätsdifferenz.
Sollte gehen.

So gehts:
Beide Platten als /dev/hda und /dev/hdb einbauen, dann kopieren:

dd if=/dev/hda of=/dev/hdb bs=128k

Blocksize von 128k sollte beim letzten Block auf der Platte trotzdem dafür
sorgen, dass der Rest übertragen wird. Nimmt man die default-bs von
512Bytes (iirc), dann dauert es Stunden für wenige GiB, weil dd dann für
jeden Block erst auf die eine, dann auf die andere Platte wartet.
Schon das reine Lesen ist erheblich schneller für bs >=64k 
(wobei man das ausprobieren muss, welcher Wert wie schnell geht).

Welche <bs> also nehmen?

Kleiner Test: 1GB vom RAID holen und nach /dev/null schieben mit
verschiedenen Blocksizes:

bs      Dauer[s]   bytes/sec    index   KB/t   tps
4096k      17.68    60717985     .979   128.00  463
2048k      17.32    61973023    1.000   128.00  472
1024k      18.08    59358600     .957   128.00  452
 512k      18.14    59166657     .954   128.00  451
 256k      17.66    60775066     .980   128.00  463
 128k      17.81    60263942     .972   128.00  459
  64k      18.25    58830733     .949    64.00  897
  32k      21.36    50249524     .810    32.00 1533
  16k      23.81    45087817     .727    16.00 2751
   8k      30.22    35519749     .573     8.00 4335
   4k      44.90    23912808     .385     4.00 5838
   2k      74.34    14442329     .233     2.00 7051
   1k     141.50     7588022     .122     1.00 7410
 512      276.91     3877499     .062     0.50 7573

KB/t:  laut iostat die Transaktionsgröße  an das Device
tps:   Anzahl der Transaktionen / sec (aus bytes/sec)


< IMHO >
Bei maximaler Blockgröße von 128kB schafft das Device ca 450-470
Transaktionen pro Sekunde. Das heisst hier ist eine Sättigung. Mehr geht
einfach nicht. 

Die Schwankungen für <bs> > 128k würde ich auf eine Messergebnis-Streuung 
zurückführen. Bei mehrfachen Messungen für die gleiche <bs> schwanken die 
Werte leicht, weswegen ich die Werte für index>0.95 nicht überbewerten
möchte.

Theoretisch sollte das Durchsatz-Maximum bei <bs>=<bs_max> erreicht sein.
dd scheint bei <bs> >> <bs_max> etwas sinnvoller mit der CPU umzugehen.
Das macht aber in der Testumgebung nicht einmal 3% Durchsatzgewinn aus.
Falls es nicht einfach nur Messwert-Schwankungen sind.

Das Device schafft maximal ca 7570 Transaktionen pro Sekunde, wenn die
Blockgröße <bs> deutlich kleiner als <bs_max> ist. Da spielt die Latenz
wohl eine Rolle, die das Device (Controller?) gegenüber dem System hat.

< /IMHO >

Kleine Blockgrößen als 512 werden vom Device abgewiesen
# dd if=/dev/ar0s1c of=/dev/null bs=256
dd: /dev/ar0s1c: Invalid argument

Fazit dürfte also sein: 

Für "dd" sollte man für <bs> mindestens einen Wert angeben, der über der 
max. Blockgröße für das Device liegt. Das sollte in der Regel 64k oder 
mehr sein. Ein "gerades" vielfaches von 64k kann nicht schaden, zB 256kb. 

Mir ist unklar, ob beim Spiegeln von Platten (Linux: hda -> hdb) bis zum
letzten Byte übertragen wird, auch wenn dadurch der letzte Block in dd
nicht mehr ganz aufgefüllt wird ( Kapazität: xyz.5MB, bs=1m --> wird das
letzte halbe MB trotzdem übertragen? )

Testumgebung für die Werte oben:
( 
  getestet mit 
    dd if=/dev/ar0s1c of=/dev/null bs=<bs> count=<1024^3/bs>

  auf einem Testsystem 
    PIII/800MHz/512MB RAM/FreeBSD 5.4-STABLE 

  mit dem Onboard-Controller 
    atapci1: <HighPoint HPT370 UDMA100 controller> 
    ata2: channel #0 on atapci1
    ata3: channel #1 on atapci1

  den Platten
    ad4: 117800MB <IC35L120AVVA07-0/VA6OA52A> [239340/16/63] at ata2-master UDMA100
    ad6: 117800MB <IC35L120AVV207-0/V24OA63A> [239340/16/63] at ata3-master UDMA100

  als RAID
    ar0: 235600MB <ATA RAID0 array> [30034/255/63] status: READY subdisks:
    disk0 READY on ad4 at ata2-master
    disk1 READY on ad6 at ata3-master
)

MfG
-- 
Raphael Becker                                    http://rabe.uugrn.org/
                      http://schnitzelmitkartoffelsalat.und.rahmspin.at/
.........|.........|.........|.........|.........|.........|.........|..