* David Haller wrote on Wed, Dec 21, 2005 at 05:16 +0100:
$ 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 :-))
Aeh? Bei mir geht das (ohne das '$ ' am Anfang der Zeile latuernich). Direkt mit C&P aus deiner Antwort...
"print s/10024" ergibt bei Dir 7.8?! Bei mir kommt statt:
8414461440 7.836 GB
link:~ # echo 's=512 * 1023 * 255 * 63;s; scale=3; print s/10024, " GB\n";' | bc 8414461440 839431.508 GB na egal.
Ja klar, Standard: bei Erreichen eines Limits Datentyp/Size verdoppeln. Hält dann meist weniger lange, als man dachte :)
Aeh, 2*28 != 48. (lol, mist, nicht 24??? Ausrede such.... ähhh..... AHH!)
Das stimmt, aber "doppelt so viel wie circa drei byte" sind halt "circa sechs byte". Ich finde ggf. einen Ingenieur, der das bestätigt (ich bin ja nur Informatiker und müsste Dir ja uneingeschränkt Recht geben).
Dass sich die Festplattenkapazitaet mit den bekannten auf magnetischen Effekten basierenden Techniken und Partitionierungs- und Addressierungsmethoden nochmal ca. um den Faktor 2^18 (ausgehend von noch fiktiven 512 GB Modellen) erhoehen laesst bezweifle ich doch sehr stark.
<btw> Das hörte man schon immer und nie war's wahr. Nimmt man halt polymäre (wie schreibt sich das? polymere :)) Speicher oder das Spezial-Schwarze-Loch-mit-Lesemöglichkeit :) Sind dann halt keine magnetische Effekte aber kann man abwärtskompatibel machen, und sich wundern, warum /boot auf den ersten 0.000000000001% liegen muss LOL </btw>
IMNSHO muss da was voellig anderes her, und dann kann man auch gleich eine andere Addressierungsmethode waehlen, ohne auf Altlasten zu achten.
Himmel, dann geht MS DOS aber doch nicht mehr?! :-)
Ich vermute, dass man erst mit holographischen o.ae. Speichermedien in die Gegend der Petabytes kommt. Selbst bei "fetten" RAID Verbuenden aus z.B. 2^10 Einzelmedien.
lol das Tausend-Platten-Heizkraftwerk
Die 24 Bit mehr tun bei UDMA 166 auch nicht mehr so weh :)
UDMA 166? Gips das??
öhmm... Bei 10 Petabyte Platten bestimmt, oder?
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?
Nö. Das RAM ist bei dem Szenario sowieso unterbeschaeftigt. Selbst mein voellig veraltetes SDRAM mit 100 MHz schafft ueber den FSB... aeh, ehrlich gesagt, keine Ahnung... jedenfalls ueber 100 MB/s (der PCI-Bus schafft IIRC 133 MB/s) und selbst die schnellsten Platten liefern z.Z. max. 80 MB/s sobald deren Cache leer ist / nicht passt. Und beim Schreiben sind die Platten i.d.R. eher langsamer.
Ja, eben! Da Speicher so schnell ist, kann man den benutzen, um lesen und schreiben zu paralleliesiern. Würde man ganz grosse size nehmen, würde dd einmal lesen und dann einmal schreiben. Bei 50MB/s also 25MB/s (erstmal einmal lesen, dann einmal schreiben dauert doppelt so lange wie einmal lesen). Nimmt man kleinere size, könnte man theoretisch auf bis zu 50 MB kommen (es wird gleichzeitig gelesen und geschrieben).
Ich habe gestern mal verschiedene Blockgroessen getestet, das war aber aus dem Linux-Platten-Cache, nicht von Festplatte, da hatte ich IIRC bei bs =~= 64-2048 KB das beste Ergebnis. Kann gut sein, dass die 1M Variante recht nah am Optimum liegt. Hm. Probier's doch mal mit folgendem, von dem ich vermute, dass es das Optimum ist:
awk '/max_kb_per_request/ { k=$2; } /multcount/ { m=$2; } END { print k * m * 1024; } ' < /proc/ide/hdc/settings 2097152
Das Ergebnis als 'bs=' fuer dd sollte nach meinem Verstaendnis und Experimenten das schnellste sein, hier also "bs=2M".
Ja, müsste man mal machen, wenn Zeit... Spannend. Aber vermutlich ist 2M und 1M ein ganz kleiner Unterschied nur, muss man schon statistisch messen etc. :)
BTW: Wie schaltet man den Plattencache von Linux aus?
raw-block-device nehmen. Gibt's für Datenbanken. Vergessen, wie die heissen. /dev/raw/raw1? Keine Ahnung, wie man die benutzt. Nein, ich weiss auch nicht wo's steht :(
Huch? Eine Frage von mir? *Rotes Kreuz im Kalender mach* *scnr&lol*
:)
Eigentlich müsste man für so einen Test ja raw an die Platten gehen - kann wohl Linux inzwischen sogar.
Aeh, was meinst du mit "raw an die Platten"? Ohne FS geht's ja schon immer via '/dev/[sh]dXY', via '/dev/[sh]dX' sogar ohne Partitionierung. Oder meinst du (s.o.) z.B. am Cache vorbei? Das Frage ich mich auch gerade, es muesste aber gehen (/dev/raw?) und das schon laenger.
ja, genau.
Achso, ich verwende mind. Anfang '00 nur noch selbstgebackene Vanilla-Kernels. Das kann, muss aber nicht, relevant sein. ;)
<btw> Komisch, ich verwende seit '01 (?) keine mehr, weil mir das zu stressig bei updates war. Ich bin halt ein fauler Mensch... :-) </btw> oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.