Ext4 auf USB-Festplatte sehr langsam beim DVD Authoring

[buzz768]

Ich habe eine neue 1,5 TB USB 2.0 Festplatte mit ext4 formatiert und mit rsync bereits über 150 GB an größeren Dateien problemlos darauf kopiert. Nun möchte ich die Platte aber auch als temporären Speicher nutzen, etwa zum Erzeugen von DVD-Video-Dateisystemen (Authoring). Dabei fällt jedoch unangenehm auf, dass die Platte noch viele Minuten nachdem das Authoring abgeschlossen zu sein scheint, aktiv ist. Lesende Zugriffe auf die Festplatte sind in dieser Zeit sehr langsam, auch lässt sie sich nicht aushängen.

Bei einer älteren mit ext3 formatierten USB-Festplatte hatte ich dieses Problem nicht. Zum Vergleich habe ich nacheinander auf beiden Festplatten (beide an derselben USB 2.0 PCI-Karte) das DVD-Verzeichnis so erstellt:

dvdauthor -t -o /mnt/dvd file.mpg && dvdauthor -T -o /mnt/dvd && umount /mnt/

und nebenher jeweils iostat laufen lassen. Auf der ext3-Festplatte dauerte die Prozedur 6 Minuten, auf der ext4-Festplatte dagegen 17 Minuten.
Hier las ich, dass die Servicetime (svctm) von besonderem Interesse ist und habe deshalb den Verlauf mal grafisch dargestellt:



Die anderen Werte nach 2, 5 und 10 Minuten

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz    await  svctm  %util
sdc (ext4)        0,00  3237,07    0,00  112,42     0,00    13,15   239,59   142,68  1228,24   8,91 100,20
sdd (ext3)        0,00  3151,50    0,00  115,57     0,00    12,81   226,97   143,01  1238,91   8,64  99,80

sdc (ext4)        0,00     0,00    0,40   26,25     0,00     0,10     8,00   287,77 10885,29  37,59 100,20
sdd (ext3)        0,00   198,40  143,29  188,18     0,56     1,51    12,79   141,17   436,98   3,02 100,20

sdc (ext4)        0,00     0,00    0,00   26,05     0,00     0,10     8,00   143,85  5505,02  38,46 100,20
sdd (ext3)        0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00     0,00   0,00   0,00

Was vielleicht eine Rolle spielt, ist, dass dvdauthor nach rund 4 Minuten mit dem "fixing VOBU" beginnt, also die zuvor erstellten, bis zu 1 GB großen VOB-Dateien noch einmal überarbeitet.

Nun stellt sich die Frage: Gibt es ein Problem mit der Festplatte an sich oder liegt es am ext4-Dateisystem? Muss ich bestimmte Optionen im ext4-Dateisystem einstellen oder die Platte mit bestimmten Optionen mounten?
Ich habe es schon mit barrier=0 versucht, aber das ergibt keinen Unterschied. Vielleicht hat ja jemand eine Idee.

Hier noch die Ausgabe von tune2fs -l:

Filesystem volume name:   Elements
Last mounted on:          /mnt
Filesystem UUID:          e2d96fdf-853c-4e94-ad8c-21edc6eb472c
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              91578368
Block count:              366284000
Reserved block count:     1831420
Free blocks:              313584639
Free inodes:              91578145
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      936
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Wed Jun  2 10:35:48 2010
Last mount time:          Thu Jun  3 18:26:20 2010
Last write time:          Thu Jun  3 18:26:20 2010
Mount count:              17
Maximum mount count:      27
Last checked:             Wed Jun  2 10:35:48 2010
Check interval:           15552000 (6 months)
Next check after:         Mon Nov 29 09:35:48 2010
Lifetime writes:          212 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      7b255438-74ff-40e1-b415-c7adb8431fa0
Journal backup:           inode blocks

[buzz768]

Ich habe die neue Festplatte jetzt einmal mit ext3 formatiert, und es zeigt sich leider das gleiche Verhalten wie bei ext4.

[Aqualung]

Untersuche beide Platten mit bonnie++.

Prüfe, ob beide Platten als USB 2.0 eingehängt werden.

Irgendwie erinnert mich das an die Anfangstage von USB 2.0, wo mancher Rechner eine absurd hohe load schob - war damals ein IRQ-Problem.

[buzz768]

Danke für die Hinweise. Beim einfachen Kopieren liegt die durchschnittliche Geschwindigkeit beider Platten bei über 12 MB/s, das wäre mit USB 1.1 nicht möglich. Nachfolgend die Benchmark-Ergebnisse, im Anhang auch noch einmal etwas übersichtlicher als HTML-Datei. Auffällig ist der große Unterschied bei den Random Seeks.

Version  1.03e      ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
alte HD       1512M 13783  73 15087   9  7300   4 15651  74 20940   7 193.7   1
neue HD       1512M 12431  66 13415   8  6935   4 15211  74 20565   7 106.8   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alte HD          16 23006  91 +++++ +++ +++++ +++ 14859  59 +++++ +++ +++++ +++
neue HD          16 20384  82 +++++ +++ +++++ +++ 16275  65 +++++ +++ +++++ +++

PS
alte HD =WDC WD10EAVS-00D7B1
neue HD = WDC WD15EARS-00Z5B1

PPS
Die verbaute Festplatte verwendet offenbar 4 KByte großen Datenblöcke (es gab hier neulich diesbezüglich auch einen Thread)
http://brain4free.org/wiki/doku.php/...t_hd_mit_linux
Nur sinkt die Geschwindigkeit auch nach einer Stunde nicht auf jene 1MB/s, hm. Ich werde die Anleitung jetzt aber mal befolgen.

[oziris]

Was mir beim kopieren großer Dateien immer auffällt ist der Cache. Linux cacht erstmal jede Menge und da geht ggf. eine Fortschrittsanzeige zunächst sehr schnell voran und dann geht es plötzlich langsamer, weil dann der Cache voll ist und die wahre Schreibgeschwindigkeit sich bemerkbar macht. Bei umount dauert das dann evtl. auch nochmal, bis der Cache zuende auf die Platte geschrieben ist, wenn man direkt nach dem Kopieren umounted. Möglicherweise hilft Dir das irgendwie.

Außerdem könnte das Journal den Prozess auch verlangsamen.

Ich finde, Du solltest mal mit den mount-Optionen experimentieren, um zu sehen, ob es etwas damit zu tun hat.

// speziell auch mit sync und noatimes usw.

[buzz768]

Danke auch dir, oziris, für die Tips. Das Problem bestand in diesem Fall aber tatsächlich darin, dass die Partition nicht an 4 Kbyte Blockgrenzen ausgerichtet war (ab Werk schon, ich hatte es verschlimmbessert). Nachdem das nun korrigiert ist, erweist sich die neue Platte als einen Tick schneller als die alte Platte, das Authoring ist gut eine halbe Minute früher fertig und die Platte danach nicht mehr aktiv. Benchmark nach der Korrektur:

Version  1.03e      ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
alte HD ext3  1512M 13783  73 15087   9  7300   4 15651  74 20940   7 193.7   1
neue HD ext4  1512M 15386  78 17217   8  7372   4 15497  74 21605   7 191.7   1
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min        /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
alte HD ext3     16 23006  91 +++++ +++ +++++ +++ 14859  59 +++++ +++ +++++ +++
neue HD ext4     16 20577  98 +++++ +++ +++++ +++ 21071  98 +++++ +++ 17523  56