Performance beim Dateikopieren mit Linux (ext3, jfs, xfs, ...)

Zitat

Original von hjs
Transfer per FTP via Gbit Intel - Transfer bei 2GB Datei 54 MB/s

könntest du mal probieren wie es zwischen zwei Platten in einem Rechner aussieht?

wir haben gerade das Scenario nochmal auf einer AMD64-Maschine ausprobiert (ext3) -> Ergebnis max 35MB/sec

Gruß, Oliver

Hallo,

ich denke nicht, dass das Filesystem bei einer solchen Aufgabe eine entscheidende Rolle spielt. Dieses ist für die Speicherung von Verwaltungsinformationen zuständig, die Daten selbst dürften (geringe Fragementierung vorausgesetzt) unter ReiserFS nicht anders auf der Platte landen als unter FAT32. Was anderes wäre es, wenn Du eine Mio Dateien a 10k kopieren würdest.

Hast Du ansonsten bei dem Windows-Test mal die HD-LED beobachtet? leuchtet diese etwa noch einige Sekunden nach dem Ende des Kopierens? Es ist immer ungünstig, für Festplattentests Dateien in der Größenordnung des Arbeitsspiechers zu verwenden.

==> nimm bei 1GB RAM mindestens eine 10GB-Datei, wenn der Test etwas aussagen soll

Viele Grüße,
Holger

Zitat

Original von Full_ack

könntest du mal probieren wie es zwischen zwei Platten in einem Rechner aussieht?

wir haben gerade das Scenario nochmal auf einer AMD64-Maschine ausprobiert (ext3) -> Ergebnis max 35MB/sec

Gruß, Oliver

Alles anzeigen

Wenn ich mal keinen der beteiligten Rechner brauche ...

HJS

So, ich habe jetzt mal einen wirklich präzisen Versuch gestartet.

Ich habe das ganze auf einer Athlon 64 Plattform mit 1GB Ram auf einem Nvidia Board gestartet. Bei beiden Tests war das System absolut identisch, ich habe unter Windows XP lediglich die Treiber installiert und Schluss. Unter Linux hatten alle Platten ext3 und unter Windows sowohl einmal NTFS wie auch fat32. Gemessen habe ich einmal mit SATA und einmal mit UDMA Platten. Kopiert wurden 8 .vdr Dateien mit insgesamt ca 5GB. Ich habe bei Windows wirklich gewartet, bis die Platten standen, d.h. der Cache spielte auch keine Rolle mehr.

Ergebnisse:

2 SATA PLatten Linux, ext3: 34,5 MB/sec
2 UDMA Platten Linux, ext3: 32 MB/sec

Bei Windows nur die SATA-Platten:

2 SATA-PLatten, NTFS zu NTFS: 53,5 MB /sec
2 SATA-PLatten, NTFS zu FAT32: 54,1 MB/sec
2 SATA-PLatten, FAT32 zu FAT32: 54,8 MB/Sec

Da hat man doch wohl keine Fragen mehr oder???

Letzte Idee, die ich noch habe, nachdem ich jetzt sowohl Intel wie auch Nvidia, Sata wie auch Udma, Athlon 64 wie auch Pentium 4 probiert habe: Gibt es noch eine Kerneloption, die in irgendeiner Weise für das Ergebnis sorgt???

Habe übrigens über SUSe Live DVD und Knoppix mal getestet, das Ergebnis blieb gleich. Auch habe verschiedene Filesysteme unter Linux nicht wirklich was gebracht, das Schnellste hier war jfs mit + 2MB/sec gegenüber ext3.

mfg

Oliver

Und noch einer, der seinen Senf dazugeben muss:

Um rauszubekommen, ob das Interface der Flaschenhals ist, kannst Du mal Daten direkt von /dev/zero ziehen.

dd if=/dev/zero of=/tmp/test.big bs=1M count=1024

uwe

Ich komme dann mit 60er 5400er Platten so auf 30MB/s (DMA-66)
(und spasseshalber gerade auf einem SAN via Fiberchannel: 260MB/s (Sun V890))

umaier: Jau du hast Recht. Habe das gerade mal getestet und komme auf 55-60 MB pro Sekunde mit dem dd Befehl. Aber was jetzt tun?!

Oliver

Tja, damit können wir die Schnittstelle als Fehlerursache ausschliessen.

Nett wäre jetzt noch, wie sich das parallel verhält:
dd auf beide Platten zur gleichen Zeit. Ich würde erwarten, dass sich das nicht weiter stört, weil jede Platte ihren eigenen Kanal hat. Aber nur zur Sicherheit.

Dann bleibt noch cp selbst. Um aus beiden Platten das Optimum rauszuholen muesste er quasi parallel den neuen "Block" von der einen Platte lesen während er den alten "Block" noch auf die andere schreibt. Und ich glaube da könnte es haken, weil er die Daten erst angekommen sehen will, bevor er wieder liest (das weiss ich aber nicht sicher!).

Falls Du auf den Platten ufs,ext2 oder ext3 drauf hast, könntest Du die Platten mal mit -o async mounten um das zu umgehen. Und dann einfach nochmal probieren.

uwe

So kleiner Test - habe allerdings nur 40 Pol Kabel an 2nd Master ( 120er )
Dann schafft er nur 22 MB/s - auf der 200er hin und her sinds 32 MB/s .
Mal schauen ob ich noch n 80pol rumfligen habe - mal sehen , was dann rauskommt ...

HJS

Ich hab es etwas weiter oben schon einmal angefragt, werden die Tests unter Linux mit einem 2.4er oder einem 2.6er Kernel gemacht ?

tüddelkopp: Habe in meiner Not schon knoppix mit 2.4er gebootet, Ergebnis gleich; ansonsten 2.6er.

mfg

Oliver

Zitat

Original von Full_ack
tüddelkopp: Habe in meiner Not schon knoppix mit 2.4er gebootet, Ergebnis gleich; ansonsten 2.6er.

Hattest Du denn auch mittels hdparm den DMA-Modus aktiviert?
Meine, der ist bei Knoppix standardmäßig aus.

Dann wäre ja alles klar.

DMA is on, believe me...

Oliver

P.S.: Da ich nicht jedes mal für den LinVDR selber kompilieren will, fällt 2.4 eh weg.

Zitat

Original von Full_ack
DMA is on, believe me...

Okokok

Dann teste das Ganze doch mal ohne Dateisystem:

dd if=/dev/zero of=/dev/hdX1 bs=1M count=4096

Hi,

wie habt ihr denn auf Linux kopiert ? Mit cp ? Habt ihr auch mal dd mit einer großen bs probiert (zum Kopieren) ? Habe hier einen interessanten Artikel gefunden. Das sgp_dd findet man im Debian-Paket sg3-utils.

Nur so eine Idee...

Gruß
Mag1c

Ja, das klingt vernünftig.

Ich habe nochmal meine obigen Ausführungen zum cp überdacht: ich glaube jetzt, dass der Cache die Performance kaputtmacht:

Stellen wir uns einen kleinen Puffer vor
* die Daten werden von Platte 1 gelesen
* und nach Platte 2 geschrieben
* währenddessen hat Platte 1 via read-ahead seinen Buffer schon wieder gefüllt, der jetzt sofort komplett ausgelesen werden kann
* die Daten gehen nach Platte 2, während Platte 1 seinen Cache schon wieder füllt
* usw.

Beim grossen Puffer:
* ...
* und nach Platte 2 geschrieben
* der read-ahead buffer ist zu klein und cp muss warten, bis die Daten in den Kopierpuffer 'getröpfelt' sind.

=> wenn man irgendwie schafft, den Kopierpuffer zu verkleinern, dann müßte auch die Performance entsprechend steigen. Ideale Größe wäre so 1-4 MB (Platten haben üblicherweise so 2-8 MByte Cache).

Windows benutzt möglicherweise die Sektorsize, das ist hier eindeutig ein Vorteil. Der Commandoverhead ist zeitlich bei 100er IDE zu vernachlässigen.

uwe

Ja, ich denke das wird es sein. Mann könnte ja auch das dd Kommando zum kopieren nehmen, ich habe auch dd_rescue probiert, ich weiß nur noch nicht, wie ich das bei mehreren Dateien anstelle.

Gruß

Oliver

Da faellt mir ein, wie man meine Theorie testen koennte:

Kleiner Buffer:
dd if=<Datei von Platte 1> of=<Datei von Platte 2> bs=1M count=10000

Grosser Buffer:
dd if=<Datei von Platte 1> of=<Datei von Platte 2> bs=100M count=100

Stimmt meine Theorie und dd benutzt bs als Puffergroesse, dann muesste hier ein Performanceunterschied sichtbar sein. dd ohne bs benutzt m.W. 512 Bytes.

uwe

Moin moin,
mal unabhängig davon das die Blockgrösse natürlich schon etwas Einfluss auf derartige Geschwindigkeitsmessungen hat sind Anpassungen nur in Spezialfällen nötig und sinnvoll.
Da einer meiner Rechner gerade mal eine grössere Platte brauchte, hab ich vorher mal ein bisschen "draufloskopiert".
Ergebnis:
BS Kanotix 2005-03 kernel 2.6.11.11
MB Epox 8rda3i (Nforce2) hda: SP1614N hdc: ST3250823A
beim kopieren von hda1 nach hdc1(xfs) werden immer Werte grösser 50MB/sec angezeigt ( mc mit 2GB-Dateien).
Kopiere ich allerdings von hda10 (letzte Partition) werden nur noch ~38MB/sec erreicht -> das die Übertragungsrate von Festplatten im inneren Sektorenbereich deutlich nachlässt sollte doch eigentlich bekannt sein, oder ?

Nur der Vollständigkeit halber, die Werte entsprechen weitgehend denen unter BartPE(WinXP)

mfG
Carsten