Hallo, Am Mon, 19 Dec 2005, Steffen Dettmer schrieb:
* David Haller wrote on Sun, Dec 18, 2005 at 23:55 +0100: [..]
$ cat /proc/ide/hdc/geometry logical 19457/255/63 [..] D.h. bs == [Sektorgroesse in Bytes] * [Sektoren pro Kopf] * [Koepfe pro Zylinder ] == Groesse eines Zylinders
Ahh, interessant. (255 * 63, und sowas rechnet man auf Computern, schon lustig :))
Liegt an dem Format der Partitionseintraege (im CHS-Format, bei LBA48 fuer Platten > 127 GB reichen die 32 eines LBA-Eintrages nicht): Zylindernummer: 10 bit => max. Zylinder: 2^10-1 = 1023 Kopfnummer: 8 bit => max. Koepfe: 2^8-1 = 255 Sektornummer: 6 bit => max. Sektoren: 2^6-1 = 63 Diese 24 bit werden zusammen in 3 Byte gepackt und in der PT gespeichert. Und das sind die Limits von CHS. Und daraus ergibt sich auch die bekannte Grenze, an die du dich wohl noch erinnern kannst: $ echo 's=512 * 1023 * 255 * 63;s; scale=3; print s/10024, " GB\n";' | bc 8414461440 7.836 GB an der damals diverse BIOSe mangels LBA Modus gescheitert sind und warum unter Linux die Partition mit /boot/ innerhalb der ersten ~8 GB liegen musste. Das naechste "harte" Limit war o.g. ~127 GB bei denen die 28 bit eines LBA-Eintrages nicht mehr reichen (4 bit sind reserviert). Also musste man den CHS-Eintrag opfern, damit man Partitionen mit mehr als 2^28-1 Sektoren verwenden kann. $ echo 's=2^28-1;s; scale=3; print s / 2/1048576, " GB\n";' | bc 268435455 127.999 GB Das hat dann Maxtor[1] vorgeschlagen und mit der Version 6 des ATA-Standards wurde das dann festgelegt. Aktuell ist IIRC ATA-7. Und gibt's auch im Web zum runterladen.
Grund der Aktion: dd liest so ganze Bloecke, und auch der letzte Block ist vollstaendig. Da ich eigentlich schon immer (also seit '96) eine */255/63 Geometrie verwende und mir die knapp 8M als Blockgroesse bei dd reichen...
Sollte man nicht Blöcke kleiner als Schreibcache nehmen, damit Lesen und Schreiben "ideal" paralelisiert werden kann? CPU Leistung ist doch meist genug da, oder? Hab immer so 1MB Blockgrösse genommen, mmm...
Hm. Bringt vermutlich nix, denn die Platte muss ja sowieso sequentiell lesen. Und das kann die offenbar besser "en bloc" wenn man dd mit einer recht grossen bs= nimmt. Mit einem bs=512 (default) ist es schnarchlangsam, wohl weil dd / der Kernel pro Block eine "Anfrage" an die Platte schickt. Mit groesseren Bloecken gibt's weniger Anfragen. BTW: hdparm -i gibt auch die ATA-Versionen aus, die die Platte vorgibt zu koennen. Hm. Ich denke die Angaben aus cat /proc/ide/hd{a,b,c}/settings \ | grep '^name\|max_kb_per_request\|multcount' geben eine sinnvolle Groesse an.
Bringt es Vorteile, wenn die Blöcke genau zur "physical" Struktur passen (die ja nicht die wirklich physikalische Plattenstruktur ist, sondern dass, was der Controller dem BIOS vorlügt :))?
s.u.
Oder ist es im Zweifelsfall ein kleines bisschen schneller
Glaube ich nicht. Aber wie gesagt, du solltest eine groessere bs waehlen als der default. Meine Platten moegen lt. der /proc Angabe wohl bs=128k am liebsten.
und Du weisst diese Zahlen eh auswendig und nimmst sie daher?
Fast. Ich weiss auswendig, was ich multiplizieren muss ;)
Genaugenommen hab ich's bei hda1 also auch falsch gemacht, denn auch diese Partition ist um einen Kopf "verkuerzt", da im ersten Sektor des ersten Kopfes eben der MBR steht. Fuer hda2-hda4 gilt es aber.
Na gut, aber dann bekommt man es doch eh nicht hin, genau "synchron" mit dd zu lesen, weil man doch dann entweder ein offset von diesem ersten Kopf mit rumschleppt oder - wenn man einen weniger liest - bei allen folgenden immer einen zu wenig hat und sich daher alles verschiebt? Oder?
Jup.
Ist aber schon interessant, was man alles so über "dd" im weiteren Sinne wissen kann :-)
*g* -dnh [1] da helf' ich dem sigmonster mal nach: -- Naja, zumindest war Maxtor "weitsichtig": mit einer 48bit-Adressierung kann man 134217728 GB (128 Petabyte) ansprechen, das sollte eigentlich fuer ein paar Jaehrchen reichen, oder? ;)) [David Haller in suse-linux]