Hallo Liste. Ich möchte ein Image einer Partition erstellen, und zwar im Prinzip so: dd if=/dev/sda1 | zip | split -b 500m Jetzt nölt zip aber nach 4 GB, daß der Datenstrom zu lang sei. Wie kann ich denn den Strom in Häppchen verpacken, so daß zip damit klarkommt? Ich könnte natürlich dd ... | split ... | zip ... eingeben, aber zip kann ja die Häppchen nicht so schön benennen wie split. Wie macht man das sinnvollerweise? Danke. PS: Gruß aus London... Hallo Thomas! -- Andre Tann
* Andre Tann wrote on Sun, Dec 18, 2005 at 15:34 +0100:
Ich möchte ein Image einer Partition erstellen, und zwar im Prinzip so:
dd if=/dev/sda1 | zip | split -b 500m
Jetzt nölt zip aber nach 4 GB, daß der Datenstrom zu lang sei. Wie kann ich denn den Strom in Häppchen verpacken, so daß zip damit klarkommt?
<geraten> Ist das ein zip-Problem, weil es evtl. versucht, Dateiinformationen mit ins ZIP zu packen? Meine mich erinnern zu können, sowas mal mit gzip oder bzip2 gemacht zu haben (und ging). </geraten> Der Konstrukt hat IMHO den Nachteil, dass ein einziger Bitfehler (insbesondere vorn) das gesammte Image "kaputt" macht, also bei Band- oder CD-R/DVD-R Archivierung evtl. nicht so günstig ist. Wenn /dev/sda1 ein linux-Filesystem enthält, könnte es Platz sparen, vorher unbenutzte Bereiche zu "nullen", da sollte $ mount /dev/sda1 /mnt $ dd if=/dev/zero of=/mnt/delete_me.tmp $ rm /mnt/delete_me.tmp evtl. helfen.
dd ... | split ... | zip
Ich glaub, das Problem ist, dass zip nicht wirklich auf streams arbeitet, weil es sozusagen "tar mit gzip zusammen" ist. Beispiel mit gzip: steffen@link:~/t> echo "1234" | split -b 2 - file_ && gzip file_* steffen@link:~/t> l insgesamt 28 drwxr-xr-x 2 steffen users 4096 2005-12-18 16:08 ./ drwxr-x--x 103 steffen users 12288 2005-12-18 16:07 ../ -rw-r--r-- 1 steffen users 30 2005-12-18 16:08 file_aa.gz -rw-r--r-- 1 steffen users 30 2005-12-18 16:08 file_ab.gz -rw-r--r-- 1 steffen users 29 2005-12-18 16:08 file_ac.gz ist doch wie erwartet? Der Nachteil ist hier natürlich, dass die Files unterschiedliche Länge (bei Dir dann u.U. deutlich kleiner als 500m) haben. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hallo Steffen, Steffen Dettmer, Sonntag, 18. Dezember 2005 16:11:
Der Konstrukt hat IMHO den Nachteil, dass ein einziger Bitfehler (insbesondere vorn) das gesammte Image "kaputt" macht, also bei Band- oder CD-R/DVD-R Archivierung evtl. nicht so günstig ist.
Das weiß ich, ist in meinem Fall aber egal. Ich werde die Sicherung doppelt auf Festplatte haben, und beide Versionen mit md5sum prüfen. Muß auch nur ein paar Stunden halten. Danach will ich das Image wieder zurückziehen, und gut ist.
Wenn /dev/sda1 ein linux-Filesystem enthält, könnte es Platz sparen, vorher unbenutzte Bereiche zu "nullen", da sollte $ mount /dev/sda1 /mnt $ dd if=/dev/zero of=/mnt/delete_me.tmp $ rm /mnt/delete_me.tmp evtl. helfen.
OK, danke für den Tip, kannte ich noch nicht.
steffen@link:~/t> echo "1234" | split -b 2 - file_ && gzip file_* steffen@link:~/t> l insgesamt 28 drwxr-xr-x 2 steffen users 4096 2005-12-18 16:08 ./ drwxr-x--x 103 steffen users 12288 2005-12-18 16:07 ../ -rw-r--r-- 1 steffen users 30 2005-12-18 16:08 file_aa.gz -rw-r--r-- 1 steffen users 30 2005-12-18 16:08 file_ab.gz -rw-r--r-- 1 steffen users 29 2005-12-18 16:08 file_ac.gz
ist doch wie erwartet? Der Nachteil ist hier natürlich, dass die Files unterschiedliche Länge (bei Dir dann u.U. deutlich kleiner als 500m) haben.
Der entscheidende Nachteil ist hier, daß gzip erst dann anfängt zu arbeiten, wenn alle Files geschrieben wurden. Und dafür habe ich leider hier nicht genug Platz. Daher hätte ich gern den Strom schon komprimiert, wie er aus dd kommt. -- Andre Tann
Hallo, Am Sun, 18 Dec 2005, Andre Tann schrieb:
Das weiß ich, ist in meinem Fall aber egal. Ich werde die Sicherung doppelt auf Festplatte haben, und beide Versionen mit md5sum prüfen. Muß auch nur ein paar Stunden halten. Danach will ich das Image wieder zurückziehen, und gut ist.
Ok.
Der entscheidende Nachteil ist hier, daß gzip erst dann anfängt zu arbeiten, wenn alle Files geschrieben wurden. Und dafür habe ich leider hier nicht genug Platz. Daher hätte ich gern den Strom schon komprimiert, wie er aus dd kommt.
1. zip kann das AFAIK nicht, so auf stdin/-out arbyten... 2. ist es kein Problem fuer gzip / bzip2: dd if=/bla | gzip -c | split ... dd if=/bla | bzip2 -c | split ... Relevant ist jew. dass du die Option '-c' verwendest. BTW: ich hab das auch schon ueber's Netz gemacht: ssh root@192.168.0.2 "dd if=/dev/hda1 bs=8225280;" \ | split -b 2000000000 - /irgendwo/rechnername-hda1.img Und in diese Pipes kannst du problemlos auch noch ein '| gzip -c' reinhaengen: ssh root@192.168.0.2 "dd if=/dev/hda1 bs=8225280;" | gzip -c \ | split -b 2000000000 - /irgendwo/rechnername-hda1.img.gz Du kannst auch ggfs. auf dem entfernten Rechner komprimieren lassen, z.B. weil der die schnellere CPU hat: ssh root@192.168.0.2 "dd if=/dev/hda1 bs=8225280 | gzip -c;" \ | split -b 2000000000 - /irgendwo/rechnername-hda1.img.gz Man beachte das Quoting! Noch Fragen? -dnh --
Darum will man im Laden auch mit Bankomat bezahlen, aber online is' halt nicht. -- K. B. Pruenner (aus .at) Wie das? Die Kiste mit dem Gabelstapler vor die Kasse hinstellen und sagen: "aufmachen können se ihn selber, sollte genug drinne sein"? -- F. Wuest
* David Haller wrote on Sun, Dec 18, 2005 at 21:36 +0100: [...]
ssh root@192.168.0.2 "dd if=/dev/hda1 bs=8225280 | gzip -c;" \ | split -b 2000000000 - /irgendwo/rechnername-hda1.img.gz
Ja, fein!
Man beachte das Quoting! Noch Fragen?
Ja, hier Frage! :-) Wieso gerade blocksize 8225280? 7,84 MB, ja? Hat das einen Vorteil gegenüber "bs=8M" oder sowas in der Art? Sieht so sorgfältig gewählt aus, die Zahl 8225280... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hallo, Am Sun, 18 Dec 2005, Steffen Dettmer schrieb:
* David Haller wrote on Sun, Dec 18, 2005 at 21:36 +0100: [...]
ssh root@192.168.0.2 "dd if=/dev/hda1 bs=8225280 | gzip -c;" \ | split -b 2000000000 - /irgendwo/rechnername-hda1.img.gz
Ja, fein!
Man beachte das Quoting! Noch Fragen?
Ja, hier Frage! :-) Wieso gerade blocksize 8225280? 7,84 MB, ja? Hat das einen Vorteil gegenüber "bs=8M" oder sowas in der Art? Sieht so sorgfältig gewählt aus, die Zahl 8225280...
Ganz "einfach" *hurhur* (hda ist schlafengelegt, deswegen hdc): $ cat /proc/ide/hdc/geometry physical 19457/255/63 logical 19457/255/63 $ echo '512 * 63 * 255' | bc 8225280 D.h. bs == [Sektorgroesse in Bytes] * [Sektoren pro Kopf] * [Koepfe pro Zylinder ] == Groesse eines Zylinders Je nach Anzahl der Zylinder der (logischen!) Plattengeometrie kann man noch einen ganzen Teiler fuer die Zylinderzahl suchen, und damit die wie oben errechnete Zahl noch multiplizieren. 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... Obiges gilt uebrigens nicht fuer logische Partitionen, die sind um 1 Kopf "verkuerzt", denn im ersten Sektor des ersten Kopfes steht die Erweiterte Partitionstabelle mit dem Eintrag fuer diese Partition und die erweiterte Partition die auf die restlichen logischen LWs verweist. Erklaerung siehe tech.* aus der LILO Doku. Also ist bei 'dd if=/dev/hdXY' mit Y >= 5 eine andere Blockgroesse anzugeben, idealerweise '512 * [Sektoren pro Kopf]' also praktisch immer bs=32256. 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. Aeh, also praktisch doch nicht so geeignet ;( -dnh -- In /etc steht, was Du denkst. In /proc steht, was das OS denkt. [Thomas Blum in doc]
* David Haller wrote on Sun, Dec 18, 2005 at 23:55 +0100:
Am Sun, 18 Dec 2005, Steffen Dettmer schrieb:
* David Haller wrote on Sun, Dec 18, 2005 at 21:36 +0100: [...]
ssh root@192.168.0.2 "dd if=/dev/hda1 bs=8225280 | gzip -c;" \ | split -b 2000000000 - /irgendwo/rechnername-hda1.img.gz
Ja, fein!
Man beachte das Quoting! Noch Fragen?
Ja, hier Frage! :-) Wieso gerade blocksize 8225280? 7,84 MB, ja? Hat das einen Vorteil gegenüber "bs=8M" oder sowas in der Art? Sieht so sorgfältig gewählt aus, die Zahl 8225280...
Ganz "einfach" *hurhur* (hda ist schlafengelegt, deswegen hdc):
$ cat /proc/ide/hdc/geometry physical 19457/255/63 logical 19457/255/63 $ echo '512 * 63 * 255' | bc 8225280
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 :))
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... 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 :))? Oder ist es im Zweifelsfall ein kleines bisschen schneller und Du weisst diese Zahlen eh auswendig und nimmst sie daher?
Obiges gilt uebrigens nicht fuer logische Partitionen, die sind um 1 Kopf "verkuerzt", denn im ersten Sektor des ersten Kopfes steht die Erweiterte Partitionstabelle mit dem Eintrag fuer diese Partition und die erweiterte Partition die auf die restlichen logischen LWs verweist. Erklaerung siehe tech.* aus der LILO Doku.
Also ist bei 'dd if=/dev/hdXY' mit Y >= 5 eine andere Blockgroesse anzugeben, idealerweise '512 * [Sektoren pro Kopf]' also praktisch immer bs=32256.
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? Ist aber schon interessant, was man alles so über "dd" im weiteren Sinne wissen kann :-) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
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]
Hallo David, hallo Leute, Am Dienstag, 20. Dezember 2005 00:10 schrieb David Haller:
Hm. Ich denke die Angaben aus cat /proc/ide/hd{a,b,c}/settings \ | grep '^name\|max_kb_per_request\|multcount'
Hmm, dass von Dir mal ein useless use of cat kommt... *useless-use-of-cat-award verleih* grep '^name\|max_kb_per_request\|multcount' \ /proc/ide/hd{a,b,c}/settings sollte dasselbe machen ;-) Gruß Christian Boltz -- Journaling erhöht die Stabilität/Konsistenz des Dateisystems nach einem nötigen Filesystem-Check, der ohne Journal ein fremdes Kinderzimmer aufräumen muss ohne zu wissen, wo der Scheiß eigentlich hin soll, während er mit Journal einen Zettel vor der Tür findet, wo die Rotznase ihre Sachen zu finden wünscht. [Holger Marzen]
Hallo, Am Tue, 20 Dec 2005, Christian Boltz schrieb:
Am Dienstag, 20. Dezember 2005 00:10 schrieb David Haller:
Hm. Ich denke die Angaben aus cat /proc/ide/hd{a,b,c}/settings \ | grep '^name\|max_kb_per_request\|multcount'
Hmm, dass von Dir mal ein useless use of cat kommt...
*useless-use-of-cat-award verleih*
Nobody's perfect.
grep '^name\|max_kb_per_request\|multcount' \ /proc/ide/hd{a,b,c}/settings
sollte dasselbe machen ;-)
Ja, klar. Das kommt davon, wenn man erstmal mit $ cat /proc/ide/hdb/settings anfaengt und dann halt noch ein bisserl umschreibt und eh nicht ganz bei der Sache ist und eigentlich auch nur einmal die Titel-Zeile (die mit ^name) haben will und zu faul ist, da mit awk eine gescheite Loesung zu machen... </rausred> So, hier also noch die "elegante" Loesung, mit einer Ausgabe zu der ich vorhin zu faul war: ==== awk 'NR == 1 || /max_kb_per_request|multcount/ { print $0"\t", n ? n : "device"; } /^name/ { n=gensub(".*/(hd.)/.*", "\\1", 0, FILENAME); }' /proc/ide/hd?/settings ==== Noch Fragen? -dnh -- Niemand käme auf die Idee, Tinte mit Tinte abzuwaschen nur Blut soll immer wieder mit Blut abgewaschen werden. -- Ebner-Eschenbach
* David Haller wrote on Tue, Dec 20, 2005 at 03:44 +0100:
==== awk 'NR == 1 || /max_kb_per_request|multcount/ { print $0"\t", n ? n : "device"; } /^name/ { n=gensub(".*/(hd.)/.*", "\\1", 0, FILENAME); }' /proc/ide/hd?/settings ====
Noch Fragen?
Ja: awk: cmd. line:5: (FILENAME=/proc/ide/hda/settings FNR=1) warning: gensub: 3rd argument of 0 treated as 1 Was will mir AWK damit sagen? <btw> In Perl: perl -ane ' /max_kb_per_request|multcount/ && printf "%20s %10s %s\n", $F[0], $F[1], [split("/", $ARGV)]->[3]; ' /proc/ide/hd?/settings (braucht man nicht sed, awk, ... lernen sondern nur Perl - so man es hat) :-) </btw> oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hallo, Am Tue, 20 Dec 2005, Steffen Dettmer schrieb:
* David Haller wrote on Tue, Dec 20, 2005 at 03:44 +0100:
==== awk 'NR == 1 || /max_kb_per_request|multcount/ { print $0"\t", n ? n : "device"; } /^name/ { n=gensub(".*/(hd.)/.*", "\\1", 0, FILENAME); }' /proc/ide/hd?/settings ====
Noch Fragen?
Ja:
awk: cmd. line:5: (FILENAME=/proc/ide/hda/settings FNR=1) warning: gensub: 3rd argument of 0 treated as 1
Was will mir AWK damit sagen?
==== man gawk [umformatiert] ==== gensub(r, s, h [, t]) If h is a string beginning with g or G, then replace all matches of r with s. Otherwise, h is a number indicating which match of r to replace. ==== Bei mir funktioniert das klaglos. Allerdings ist mein gawk auch schon ein wenig aelter (3.0.4). gensub ist aber sowieso eine GNU Extension. Es sollte also: n = gensub(".*/(hd.)/.*", "\\1", 1, FILENAME); sein. Tut mir leid.
<btw> In Perl:
perl -ane ' /max_kb_per_request|multcount/ && printf "%20s %10s %s\n", $F[0], $F[1], [split("/", $ARGV)]->[3]; ' /proc/ide/hd?/settings
Schick! Ich sollte z.B. perldoc perlrun doch mal komplett lesen, der Schalter '-a' war mit bisher unbekannt ;) Ich wuerde allerdings vermutlich '(split(...))[3]' statt '[split(...)]->[3]' verwenden. Naja, ist wohl egal, ob man sich nun ne Referenz auf eine anonyme Liste oder direkt die anonyme Liste nimmt und dann deren 3tes Feld holt... Und ausserdem auch eher so, wie es -MO=Deparse ausgibt: LINE: while (defined($_ = <ARGV>)) { our(@F) = split(" ", $_, 0); printf "%20s %10s %s\n", $F[0], $F[1], [split(m[/], $ARGV, 0)]->[3] if /max_kb_per_request|multcount/; } (Zeilenlaenge von mir gekuerzt), also das "printf ... if .... Witzig finde ich aber, dass beim split das "/" zu 'm[/]' wird, aber das matching beim if nicht zu if 'm/.../'... So, das mit den Listen/-refs hat mich jetzt doch interessiert: ==== anon-list.pl ==== #!/usr/bin/perl -w use strict; use Benchmark qw(cmpthese); my $res; my $hd = "/proc/ide/hdc/settings"; ### string fuer's split my $iters = 27; ### Anzahl Zeilen in /proc/ide/hdc/settings sub anon_listref { for( 1 .. $iters ) { $res = [split(m[/], $hd)]->[3]; } } sub anon_list { for( 1 .. $iters ) { $res = (split(m[/], $hd))[3]; } } cmpthese( -1, { anon_listref => \&anon_listref, anon_list => \&anon_list } ); ==== $ perl anon-list.pl Rate anon_listref anon_list anon_listref 1793/s -- -33% anon_list 2669/s 49% -- Haette nicht gedacht, dass das so ein Unterschied ist. Endlich hab ich mal "intuitiv" die schnellere Version genommen ;)
(braucht man nicht sed, awk, ... lernen sondern nur Perl - so man es hat)
Och, ich verwende je nach Aufgabe bash, grep, ed, sed, awk oder perl... Ggfs. auch C oder C++. Ruby und Python will ich mir irgendwann mal anschauen. Mein laengstes awk-script ist z.B. $ sed -n '1,/#\{68\}/{/^#/d;p;}' ~/bin/headmidtail | wc -l 162 Zeilen lang (reiner Code, fast ohne Kommentare[1] und den code aus '$prefix/share/awk/getopt.awk'[2]). Wird ein shell, sed, oder awk-script laenger als eben ca. 100 Zeilen und/oder laeuft es laenger als ca. 10s tendiere ich stark zu perl. Bei kurzen Scripten usw. tendiere ich gegen perl, weil das doch relativ langsam startet, speziell wenn man ein paar (groessere) Module verwendet... Fuer "Kurzkram" der haeufig gestartet wird sind die anderen Programme sinnvoller, d.h. wenn ein grep, sed, awk reicht, dann nehm ich das. BTW: grep kann AFAIK nix, was sed nicht kann und sed kann AFAIK nix, was (g)awk nicht kann. Folgerung: Sobald ein 'sed' auf einer Zeile (Pipe-Kette) auftaucht ist grep ersetzbar, und beide durch 'gawk'. Bsp: grep 'foo' bar gleich sed -n '/foo/p' bar gleich awk '/foo/' bar gleich perl -ne 'print if /foo/;' bar Man kann auch, gewissermassen, mit der bash "greppen": while read l; do test "x${l//*foo*/XXX}" = "xXXX" && echo "$l"; done < bar dabei darf aber in 'bar' aber keine Zeile mit nur XXX enthalten sein. Das laeuft zwar rein in der bash ist aber trotzdem langsamer als die grep, sed awk und sogar die perl-Variante (zumindest wenn perl schon im Plattencache ist, aber bei der bash kann man da ja auch von ausgehen). Die Regular Expression (RE) Varianten unterscheiden sich aber: grep und sed verwenden Basic RE, egrep/grep -E und awk verwenden Extended RE (siehe 'man 7 regex') und perl seine eigenen (siehe perldoc perlre, nochmals maechtiger als ERE). Und perl ist nicht ganz eine Obermenge von awk, genauer gesagt, aus 'perldoc perlvar': Remember: the value of $/ is a string, not a regex. awk has to be better for something. :-) d.h. ein 'awk -F "REGEX"' kann man in perl nur (umstaendlich) nachbauen. Mir jedenfalls macht es Spass bash, sed, awk und perl usw. zu kennen / koennen und mir je nach Aufgabe das "Richtige Tool"[tm] herauszusuchen, gemaess dem Motto: "Know thy tools!" und entgegen der (rausgesuchten) sig. Achso: nix gegen perl, ich mag perl sehr, aber es ist nicht immer das richtige Werkzeug. HTH & HAND, -dnh PS: schon mal die perlsh angeschaut? [1] es gibt ein paar (3 Zeilen oder so) direkt im code, wo sie sinnvoll sind. [2] da finden sich einige interessante Funktionen, an denen man sieht, dass awk doch gerne unterschaetzt wird. -- Wenn man nur einen Hammer als Werkzeug hat, sieht jedes Problem aus wie ein Nagel.
* David Haller wrote on Wed, Dec 21, 2005 at 04:03 +0100: [...]
<btw> In Perl:
perl -ane ' /max_kb_per_request|multcount/ && printf "%20s %10s %s\n", $F[0], $F[1], [split("/", $ARGV)]->[3]; ' /proc/ide/hd?/settings
Schick! Ich sollte z.B. perldoc perlrun doch mal komplett lesen, der Schalter '-a' war mit bisher unbekannt ;)
dann auch "-npi" merken. Superwaffe das Teil.
Ich wuerde allerdings vermutlich '(split(...))[3]' statt '[split(...)]->[3]' verwenden.
Ja, ok. Aber bei so "Schnellschüssen". Ich geb zu, wollte ich erst, ging nicht, vermutlich woanders ein Problem, und fix zu gemacht :)
Naja, ist wohl egal, ob man sich nun ne Referenz auf eine anonyme Liste oder direkt die anonyme Liste nimmt und dann deren 3tes Feld holt...
Wird in beiden Fällen kopiert, glaub ich, aber split(...)[3] funktioniert nicht.
printf "%20s %10s %s\n", $F[0], $F[1], [split(m[/], $ARGV, 0)]->[3] if /max_kb_per_request|multcount/;
Das ist "print wenn match", klar, das gleiche, aber "and" find ich schon nett "match und printe". "and" kann man hier nehmen, aber "&&" ist wohl eh superbekannt und daher lesbar, sonst: /max_kb_per_request|multcount/ and printf "%20s %10s %s\n"; also (err != ok) and die geht dann gut mit or open($f) or die. Find ich Klasse: "Open or die." :-) just BTW.
(Zeilenlaenge von mir gekuerzt), also das "printf ... if .... Witzig finde ich aber, dass beim split das "/" zu 'm[/]' wird, aber das matching beim if nicht zu if 'm/.../'...
Das ist, weil der Regex "/" enthält. Schreibst Du: perl -MO=Deparse -ane ' /max_kb_pe\/\/r_request|multcount/ ' /dev/null kommt wieder m[max_kb_pe//r_request|multcount] split("/") ist ja eigentlich falsch, dann vielleicht besser split(m|[/]|, $ARGV) matcht dann wirklich Zeichenweise, könnte schneller sein, aber sieht schon komisch aus, finde ICH. Geschmackssache :)
So, das mit den Listen/-refs hat mich jetzt doch interessiert:
==== anon-list.pl ==== #!/usr/bin/perl -w use strict; use Benchmark qw(cmpthese); my $res; my $hd = "/proc/ide/hdc/settings"; ### string fuer's split my $iters = 27; ### Anzahl Zeilen in /proc/ide/hdc/settings sub anon_listref { for( 1 .. $iters ) { $res = [split(m[/], $hd)]->[3]; } } sub anon_list { for( 1 .. $iters ) { $res = (split(m[/], $hd))[3]; } } cmpthese( -1, { anon_listref => \&anon_listref, anon_list => \&anon_list } ); ====
$ perl anon-list.pl Rate anon_listref anon_list anon_listref 1793/s -- -33% anon_list 2669/s 49% --
Hey, super, fetzt ja. use Benchmark muss ich mir merken. Wirklich cool, wie schön das geht!
Haette nicht gedacht, dass das so ein Unterschied ist.
Ja, ich auch nicht! Danke für den Test! Interessant, dann kopiert () vielleicht hier doch nicht. Hab mit verschiedenen Strings probiert (lang, viele elemente, mit wenig grossen etc). Der grösste Unterschied ist bei leerem Teststring. Das klingt ja fast so, als ob die Referenzen zusätzlich nennenswert Resourcen brauchen oder split einfach verdammt schnell ist (bzw. bei ein-Zeichen-Regex direkt über strchr oder sowas sucht, das ist bei leerem String hölle schnell. Spannend.
Endlich hab ich mal "intuitiv" die schnellere Version genommen ;)
:-)
(braucht man nicht sed, awk, ... lernen sondern nur Perl - so man es hat)
Och, ich verwende je nach Aufgabe bash, grep, ed, sed, awk oder perl... Ggfs. auch C oder C++. Ruby und Python will ich mir irgendwann mal anschauen.
Ja, klar. Ich hab teils aber alte bash Scripte, wo ich mich heute ärgere, nicht gleich perl genommen zu haben. Die starten teils mehrfach perl oder bc oder expr oder so'n Mist, ist bei 5 zeilen egal, aber wenn man da loopt etc. wirds schnell langsam. Na, was rede ich, siehts Du sicher genauso und wir sind ja einer Meinung: Natürlich verwendet man eine zur Aufgabe passende Sprache. Ich hab gerade bisschen mit Prolog gespielt. Kann man zwar nicht gebrauchen, aber lustig: "Knobeln mit PL" :)
Mein laengstes awk-script ist z.B. $ sed -n '1,/#\{68\}/{/^#/d;p;}' ~/bin/headmidtail | wc -l 162 Zeilen lang (reiner Code, fast ohne Kommentare[1] und den code aus '$prefix/share/awk/getopt.awk'[2]).
Geht das auch mit 80 Zeilen Perl? :-) Nee, wichtig ist IMHO, dass man es noch verstehen kann, sonst schmeisst man es später weg und schreibt es neu. Was OK ist, wenn's was ganz spezielles ist, dass verwendet man eh selten weiter. Aber natürlich kann man auch mit awk schöne, lesbare strukturierte Programme schreiben (man != ich).
Wird ein shell, sed, oder awk-script laenger als eben ca. 100 Zeilen und/oder laeuft es laenger als ca. 10s tendiere ich stark zu perl. Bei kurzen Scripten usw. tendiere ich gegen perl, weil das doch relativ langsam startet, speziell wenn man ein paar (groessere) Module verwendet...
Liegt aber nicht am Perl: link:~ # time perl -e 'exit(0);' real 0m0.004s user 0m0.000s sys 0m0.000s sondern am Modul :) link:~ # time java (fehlermeldung, nix geladen) real 0m0.433s Faktor 100 :-)
Fuer "Kurzkram" der haeufig gestartet wird sind die anderen Programme sinnvoller, d.h. wenn ein grep, sed, awk reicht, dann nehm ich das. BTW: grep kann AFAIK nix, was sed nicht kann und sed kann AFAIK nix, was (g)awk nicht kann. Folgerung: Sobald ein 'sed' auf einer Zeile (Pipe-Kette) auftaucht ist grep ersetzbar, und beide durch 'gawk'. Bsp:
grep 'foo' bar [...] perl -ne 'print if /foo/;' bar
och, wie lang im Vergleich! Schade, kriegt man aber nicht schöner, oder?
dabei darf aber in 'bar' aber keine Zeile mit nur XXX enthalten sein. Das laeuft zwar rein in der bash ist aber trotzdem langsamer als die grep, sed awk und sogar die perl-Variante (zumindest wenn perl schon im Plattencache ist, aber bei der bash kann man da ja auch von ausgehen).
Kommt ja auch immer sehr auf die Daten an. Schätze, grep ist bei grossen Files mit wenig Treffern schnell, perl auch, bash nicht (weil interpreter).
Remember: the value of $/ is a string, not a regex. awk has to be better for something. :-)
d.h. ein 'awk -F "REGEX"' kann man in perl nur (umstaendlich) nachbauen.
Fetzt ja :) Wird awk langsam, wenn man das benutzt? Muss aufwändig sein, weil der regex ja mehr im Speicher braucht (ggf. Anfang bis nächste Zeile). Müsste man mal mit 500 MB file probieren. Ja, in Perl müsste man wohl split nehmen und dazu die gesammten Inputdaten im Speicher haben. Bei 500 MB evtl. schwierig :) Kann awk das?
Mir jedenfalls macht es Spass bash, sed, awk und perl usw. zu kennen / koennen und mir je nach Aufgabe das "Richtige Tool"[tm] herauszusuchen, gemaess dem Motto: "Know thy tools!" und entgegen der (rausgesuchten) sig. Achso: nix gegen perl, ich mag perl sehr, aber es ist nicht immer das richtige Werkzeug. (Deine sig habe ich nicht verstanden)
Da stimme ich Dir vollkommen zu :-) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
* 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.
Hallo, Am Tue, 20 Dec 2005, Steffen Dettmer schrieb:
* 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 :)
Jup :) Und man kann mit seinen Fingern bis 1023 zaehlen ;) Zumindest mit der Standardausfuehrung von Fingern. Es gibt mindestens eine Person mit 12 Fingern. Der kann an seinen Fingern bis 4096 zaehlen ;)
$ 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...
8414461440 7.836 GB
(aber Ergebnis stimmt :))
*g*
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 :)
Koennte sogar sein. Ich hatte erst unter SuSE 5.3 (Kernel 2.0.35 IIRC) eine so grosse Platte, AFAIR.
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) :)
*hehe* Bei mir hat Linux auch immer weniger Aerger mit HW gemacht als Win. Das krasseste war wohl der Versuch (so ca. Anfang 2001?), die T-Online Software fuer DSL zu installieren. Da blieb die Kiste beim Versuch die Treiber zu installieren hart stehen... Der freie Alternativ-Treiber (Name entfallen) lief tadellos *hurhur* und unter Linux lief sogar der Kernel-PPPoE-Treiber mit nem gepatchten pppd beim ersten Versuch, genau nach HOWTO. Und da sach mir noch einer, unter Win waere ja alles so einfach... Naja, das DSL unter Win wollte ich sowieso nur um z.B. alle halben Jahr oder so direkt ein Virenscanner-Update runterzuladen oder so, da ich damals Win nur noch zum Spielen verwendet habe ;)
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 :)
Aeh, 2*28 != 48. Aber ich denke, es muss sich technologisch _sehr viel_ veraendern, um mehr als 128 Petabyte auf einer "Festplatte" unterzubringen, schon heute sind wir schon sehr nahe am physikalischen Limit der Technik! Bei aktuellen HDDs sind die einzelnen "Bits" (Domaenen, die einzelnen magnetischen Partikel oder so) inzwischen so klein, dass sie "fast" schon ihre magnetischen Eigenschaften verlieren. Da kann man nicht mehr viel drehen. Im Moment verwendet man quasi die kleinsten Partikel "liegend" und die aktuellsten Modelle / Techniken versuchen nun, die Partikel "senkrecht" zur Oberflaeche hinzubekommen. Das bringt aber "nur" eine relativ geringe hoehere Datendichte (kleiner Faktor 10, eher kleiner 5, denn so klein sind die Partikel eben). Wie gesagt also, aktuell kratzt man schon am technologischen Limit (und das war schon abzusehen als Maxtor das 48bit Schema entwickelte). 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. IMNSHO muss da was voellig anderes her, und dann kann man auch gleich eine andere Addressierungsmethode waehlen, ohne auf Altlasten zu achten. 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.
Die 24 Bit mehr tun bei UDMA 166 auch nicht mehr so weh :)
UDMA 166? Gips das?? Ist UDMA-133 nicht mehr aktuell? Und gibt es Laufwerke damit, wenn es das gibt? V.a. weil SATA mit "nominell" -1500 bzw. SATA-II mit -3000 daherkommt?
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. In der Praxis bekomme ich ja z.B. mit hdparm max. ~40 MB/s aus meinen Platten, und dabei sind das recht aktuelle Modelle (SAMSUNG SP1614N und SV1604N, die sich in der Praxis nur minimal unterscheiden). Neuere Mainboard/RAM/CPU Kombinationen als meine inzwischen 6.5 Jahre alte Plattform schaffen bei RAM/CPU bis zu 3.2 GB/s! Die Festplatten sind aber dadurch nicht schneller als bei mir, grob gesagt. Wie gesagt: IIRC liegt das Maximum, das die c't bisher gemessen hat bei ca. 80 MB/s, und das ist deutlich unter dem, was sogar meine alte Kiste schafft.
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?
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". BTW: Wie schaltet man den Plattencache von Linux aus? /proc/sys/vm/buffermem gibt's bei mir (Kernel 2.4.25) nicht, obwohl in proc.txt (aber nicht eindeutig) dokumentiert... Und in den Sourcen habe ich auch nix zu "buffermem" bzw. den angeblichen Parametern darin gefunden... Huch? Eine Frage von mir? *Rotes Kreuz im Kalender mach* *scnr&lol*
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.
oder s.o., ich hab das nicht genau messen koennen ;) Bonnie habe ich nicht und will's auch nicht auf meine Daten loslassen...
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.
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.
Wenn das deutlich langsamer geht (messbar), dann macht der Kernel also gute Arbeit.
Also, in der Beziehung kommt's auf den Kernel an, siehe die IDE-Katastrophe rund um Kernel 2.4.11-dontuse... Aber generell machen zumindest die 2.0er, 2.2er, 2.4er (bis 2.4.9 oder so) sowie die 2.4er (mind. ab 2.4.16) und AFAIK auch die 2.6er Kernel einen sehr guten Job was das Thema angeht. Bei den 2.6ern bin ich mir nicht sicher, kann sein, dass da ein paar "wurmige" Versionen dabei waren... Bisher hatte ich aber immer ein gutes Haendchen was die Kernel angeht (hab mich halt auch vorher informiert ;) und war immer voll zufrieden, auch mit den 2.4.0-test{1,4,6} Kernels die ich ca. 1.5 Jahre verwendet habe (und dann direkt auf 2.4.16, die ich dann gut 2 Jahre verwendete). Achso, ich verwende mind. Anfang '00 nur noch selbstgebackene Vanilla-Kernels. Das kann, muss aber nicht, relevant sein. ;) -dnh -- *groooooooooooooooooßekeulerauskram* Du solltest jetzt besser ganz schnell laufen! -- Angelique Presse
* 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.
David Haller, Sonntag, 18. Dezember 2005 21:36:
2. ist es kein Problem fuer gzip / bzip2:
Danke, hab ich grad probiert, und geht. [Dinge über ssh]
Man beachte das Quoting! Noch Fragen?
Nee, eigentlich nicht... Quoting ist klar - was mir noch nicht so klar war, ist, daß mir ssh dasjenige auf stdout zurückgibt, was der entfernte Prozeß produziert. Aber könnte mal sehr praktisch sein. Danke und Gruß. -- Andre Tann
Hallo, Am Sun, 18 Dec 2005, Andre Tann schrieb:
David Haller, Sonntag, 18. Dezember 2005 21:36:
2. ist es kein Problem fuer gzip / bzip2:
Danke, hab ich grad probiert, und geht.
*g* Ich hab grad Lust und erklaere dazu noch was: zip ist ein "Windows" Packer, der Datei-orientiert arbeitet. D.h. er nimmt nen Archiv-Namen und ein oder mehrere Dateinamen und packt diese in das Archiv. compress, gzip und bzip2 sind "klassisch" und Stream- orientiert, d.h. die schert es nicht _was_ sie da komprimieren. Daher auch die Limitierung von compress/gzip/bzip2 auf einzelne Dateien bzw. einen "stream"; das Archiv der "vielen" Dateien muss was anderes machen, klassisch tar, wobei dann das tar gesamt komprimiert wird, oder andersrum afio, das erst die Dateien komprimieren laesst und dann die komprimierten Dateien zu einem Archiv zusammenpackt. BTW: das Debian 'deb' Format ist (oder war) ein 'ar' Archiv, das (wie bei afio) diverse (auch schon komprimierte) Dateien und ein paar Zusatzinfos zu einer Datei zusammenpackt. Als Umsteiger von Win* irritert das Verhalten der Unix-Tools erstmal, aber schaut man sich mal die Arbeitsweise an wird einem klar, dass gerade die Datei-orientierte Arbeisweise von zip einfach nicht zu Unix passt. Und bzip2 komprimiert i.d.R. auch noch besser als zip (aber langsamer), gzip AFAIK ungefaehr aehnlich. Nochmal zur Verdeutlichung: zip: komprimiert die Dateien(!, nicht bel. streams) mit einem der zip-Algorithmen und packt sie in ein Archiv: zip archive.zip * afio: komprimiert die Dateien per compress/gzip/bzip2 und packt sie in ein Archiv, aehnlich zu: compress * && ar cr archive.a *.Z gzip * && ar cr archive.a *.gz bzip2 * && ar cr archive.a *.bz2 tar c[zj]: baut ein Archiv und komprimiert dieses anschliessend, aehnlich zu: ar cr archive.a * && compress archive.a ar cr archive.a * && gzip archive.a ar cr archive.a * && bzip2 archive.a Mit dem Unterschied eben, dass compress/gzip/bzip2 im Gegensatz zu 'zip' generell "stream"-orientiert sind und sich somit wunderbar in eine Pipe einbauen lassen. Dass man fuer die Ausgabe auf stdout ein '-c' angeben muss ist IMO wohl nur der Praxis geschuldet. AFAIR ist folgendes aus 'zip -h' ein Feature der Implementation fuer Unix: If zipfile and list are omitted, zip compresses stdin to stdout. Die Win* Zips koennen das i.d.R. nicht, also sowas: bla | zip | fasel bzw.: bla | zip - - | fasel Das ist also wohl implementationsspezifisch und fuer "zip"- Implementationen eher unueblich.
[Dinge über ssh]
Man beachte das Quoting! Noch Fragen?
Nee, eigentlich nicht... Quoting ist klar - was mir noch nicht so klar war, ist, daß mir ssh dasjenige auf stdout zurückgibt, was der entfernte Prozeß produziert. Aber könnte mal sehr praktisch sein.
Ist es! :)) SSH kann "netcat over ssh" ;) BTW: alternativ kann man so z.B. tar ueber's Netz jagen: ==== eine Zeile, auf 192.168.0.2 laeuft ein Knoppix mit sshd ==== ssh root@192.168.0.2 "( cd /mnt/hda1; tar cp --atime-preserve --exclude=hiberfil.sys --exclude=pagefile.sys . ; ) " | tar xvp --atime-preserve ==== Man beachte wiederum das Quoting (also was wo ausgefuehrt wird). Wobei, AFAIR kann auch tar selber ueber's Netz, aber oben hab ich's eben per SSH gemacht (auch wenn's nur ueber ein Crossover-Kabel war); geraten muesste (ohne excludes): ssh root@192.168.0.2 \ "tar -cp --atime-preserve -f root@192.168.0.1:- /mnt/hda1" das Aequivalent sein. Wobei man statt stdout ggfs. auch gleich nen Dateinamen angeben koennen sollte: ssh root@192.168.0.2 \ "tar -cp --atime-preserve -f root@192.168.0.1:./foo.tar /mnt/hda1" Wie das aber dann mit Zugriffsrechten usw. etc. pp. aussieht weiss ich nicht, ich habe eben fuer obiges Backup die einfache Variante mittels stdin/-out genommen, weil ich da nicht viel rumprobieren musste, denn ich hatte den Laptop mit der IP .2 nur kurz zum reparieren da und wollte mich nicht gross mit der u.a. ssh(d) Konfiguration hueben und drueben (ein Knoppix auf dem WinXP Laptop) befassen. -dnh -- Bei uns sagt man, je nach dem wo man sich gerade aufhält, entweder Scheißteil oder Drecksding und manchmal auch Gehtschonwiedernichtdiescheiße dazu. -- U. Eckhardt ueber Notes
* Andre Tann wrote on Sun, Dec 18, 2005 at 23:47 +0100:
was mir noch nicht so klar war, ist, daß mir ssh dasjenige auf stdout zurückgibt, was der entfernte Prozeß produziert. Aber könnte mal sehr praktisch sein.
Ja, genauer gesagt, ist das eine Hauptfunktion. Die andere ist, das dass, was auf stdin einkommt, zum entfernten Prozess zu schicken. Und dessen Ausgaben halt zurück. Wie auch bei $ ssh $host date Eigentlich ja ganz logisch, oder? :-) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Am 18.12.2005 15:34 schrieb Andre Tann:
Ich möchte ein Image einer Partition erstellen, und zwar im Prinzip so:
Wie macht man das sinnvollerweise?
Spricht was gegen partimage? OJ -- I think a nerd is a person who uses the telephone to talk to other people about telephones. And a computer nerd therefore is somebody who uses a computer in order to use a computer. (Douglas Adams in "Triumph of the Nerds")
Am Sonntag, 18. Dezember 2005 15:34 schrieb Andre Tann:
Jetzt nölt zip aber nach 4 GB, daß der Datenstrom zu lang sei. Wie kann ich denn den Strom in Häppchen verpacken, so daß zip damit klarkommt?
Kann es sein, dass das Dateisystem, auf dem Du das zip ablegst, nicht mit Dateien größer 4GB klarkommt? So wäre es kein Problem des Programms zip. Gruß Marco
Am So d. 18 Dez 2005 22:08:48 +0100 schrieb Marco Sorich:
Kann es sein, dass das Dateisystem, auf dem Du das zip ablegst, nicht mit Dateien größer 4GB klarkommt?
Damit hat es nichts zu tun. Wie du bei http://www.info-zip.org/pub/infozip/FAQ.html#limits nachlesen kannst, kann zip keine Datei komprimieren, die unkomprimiert grösser als 2GB ist. Selbst mit entsprechenden Kompilerschaltern kann das Limit nur unwesentlich angehoben werden. Philipp
participants (7)
-
Andre Tann -
Christian Boltz -
David Haller -
Johannes Kastl -
Marco Sorich -
Philipp Thomas -
Steffen Dettmer