* David Haller wrote on Tue, Dec 20, 2005 at 00:10 +0100:
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 :))
Zylindernummer: 10 bit => max. Zylinder: 2^10-1 = 1023
Ja, zumindestens das war bekannt, genau. Trozdem lustig, normalerweise kann man alles mögliche im Kopf rechnen, wenn man die 2er Potenzen kennt :)
$ echo 's=512 * 1023 * 255 * 63;s; scale=3; print s/10024, " GB\n";' | bc
(Programm ist falsch; nur damit Du weisst, dass ich es mir wirklich angeschaut habe :-))
8414461440 7.836 GB
(aber Ergebnis stimmt :))
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.
Hatte Linux das Problem nicht selbst auch? mmm.... Musste ich nicht damals auf 2.0.34 updaten, nachdem ich mir ne grosse Platte geleistet hatte? Ach, keine Ahnung, lange her :) Jedenfalls hab ich in meinem damaligen "Server" gar keine IDE Platten ins BIOS eingetragen, und von meinem klassischen NCR-810 gebootet (ohne SCSI ROM weil im BIOS drin, jawohl, früher ging sowas mal lol) :)
Das hat dann Maxtor[1] vorgeschlagen [von sig] "weitsichtig": mit einer 48bit-Adressierung
Ja klar, Standard: bei Erreichen eines Limits Datentyp/Size verdoppeln. Hält dann meist weniger lange, als man dachte :) Die 24 Bit mehr tun bei UDMA 166 auch nicht mehr so weh :)
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.
Na ja, während die ein Platte (Ziel) schreibt, kann man von der anderen doch schon mal das nächste lesen? Um so grösser die Blöcke (also Extrem: 500 MB oder so, was halt in RAM passt), desto sequentieller müssten doch die Platten werden (eine wartet ja dann immer), oder? Wenn man von einer Platte auf die gleiche schreibt, ist vermutlich eine Blöckgrösse von 50% des "freien" RAMs angebracht, also wirklich 500 MB :) Macht das Sinn?
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.
Na gut, aber der Kernel wird doch wohl geschickt man "vielen" Anfragen umgehen? Elevator-Seeking, multi-disk-IO und was man da so braucht?
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.
mmm... Ich meine mal getestet zu haben, dass so 1 MB bei disk->disk ganz gut geht und mehr nicht langsamer wird. Gut, man hat ja noch 100-800 MB RAM frei, wenn man nix anderes macht. Eigentlich müsste man für so einen Test ja raw an die Platten gehen - kann wohl Linux inzwischen sogar. Wenn das deutlich langsamer geht (messbar), dann macht der Kernel also gute Arbeit. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.