Mailinglist Archive: opensuse-de (3763 mails)
| < Previous | Next > |
Re: DVD-RAM-Zugriffe sehr langsam/Dateisystem fuer DVD-RAMs
- From: Andreas Loesch <suseliste@xxxxxxxxx>
- Date: Fri, 24 Sep 2004 11:36:41 +0200
- Message-id: <200409241136.41550.suseliste@xxxxxxxxx>
Am Freitag, 24. September 2004 00:55 schrieb Christian Schneider:
> Am Donnerstag, 23. September 2004 22:01 schrieb Manfred Tremmel:
> > Hast Du Vergleichswerte, z.B. mit der 1 GB Datei?
> Zwecklos, da bekomme ich einfach keine reproduzierbaren und
> representativen Zeiten hin.
seltsam, auch nciht mit 2.6?
> Ich habe die gleiche 1GB Datei erneut auf
> die DVD-RAM mit ext2 geschrieben (gebootet mit SuSE-default-Kernel):
> ueber 12 Minuten! Dabei war der Desktop kaum zu benutzen (dauerndes
> Ruckeln, keine oder sehr spaete Reaktionen auf Maus- oder
> Tastaturaktionen).
>
> Da ich etwas von einem Kernel-Problem gelesen habe, das angeblich im
> 2.6er behoben ist habe ich einen 2.6er gebootet. Das Ruckeln war weg,
> das Kopieren der 1GB Datei (auf ein ext2 FS) dauerte aber nun weit
> ueber 20 Minuten!
ihc hab hier ein Debiansystem mit einem DVD-Ram (irgendsoein LG-Teil) mit
Kernel 2.6.7 und _ohne_ ide-scsi da habe ich vor einiger zeit mal Tests mit
dem ext2-FS gemacht:
andreas@einstein:~/tmp$ time dd if=/dev/urandom of=testfile bs=1024k
count=1000
1000+0 Datensätze ein
1000+0 Datensätze aus
1048576000 bytes transferred in 339,946311 seconds (3084534 bytes/sec)
real 5m39.992s
user 0m0.010s
sys 5m25.455s
1/ Filesystem mit Blockgröße von 2048 anlegen:
einstein:/media# time mke2fs -b 2048 -m 0 /dev/hdd
[...]
real 2m54.545s
user 0m0.019s
sys 0m0.199s
2/ Testdatei auf FS kopieren:
andreas@einstein:~/tmp$ time cp testfile /media/dvdram/
real 14m1.718s
user 0m0.307s
sys 0m5.083s
in diesem Zeit-Fenster ist das mehrfach reproduzierbar.
3/Filesystem mit blockgröße 4096 anlegen:
einstein:/media# time mke2fs -b 4096 -m 0 /dev/hdd
mke2fs 1.35 (28-Feb-2004)
[...]
real 1m37.748s
user 0m0.010s
sys 0m0.204s
4/ und datei kopieren
andreas@einstein:~/tmp$ time cp testfile /media/dvdram/
real 11m56.132s
user 0m0.319s
sys 0m4.486s
die blockgröße macht sich bei einer entsprechenden Datei bemerkbar :)
hier fehlen mir noch Tests mit 'realen' Dateigrößen Verteilungen aber an sich
6/ ok, wie macht sich udf?
einstein:/media# time mkudffs --media-type=dvdram /dev/hdd
start=0, blocks=16, type=RESERVED
start=16, blocks=3, type=VRS
start=19, blocks=237, type=USPACE
start=256, blocks=1, type=ANCHOR
start=257, blocks=16, type=PVDS
start=273, blocks=1, type=LVID
start=274, blocks=2236173, type=PSPACE
start=2236447, blocks=1, type=ANCHOR
start=2236448, blocks=239, type=USPACE
start=2236687, blocks=16, type=RVDS
start=2236703, blocks=1, type=ANCHOR
real 0m0.833s
user 0m0.002s
sys 0m0.008s
einstein:/media#
7/ Kopieren der Random-Datei:
andreas@einstein:~/tmp$ time cp testfile /media/dvdram/
real 11m29.087s
user 0m0.357s
sys 0m5.404s
8/ zum schluss hab ich nochmal die gleiche Zahl an Bytes aus /dev/zero bzw
aus /dev/urandom direkt auf ein Medium geschrieben:
einstein:/media# time dd if=/dev/zero of=/dev/hdd bs=1024k count=1000
1000+0 Datensätze ein
1000+0 Datensätze aus
1048576000 bytes transferred in 477,818662 seconds (2194506 bytes/sec)
real 7m57.856s
user 0m0.013s
sys 0m2.926s
einstein:/media# time dd if=/dev/urandom of=/dev/hdd bs=1024k count=1000
1000+0 Datensätze ein
1000+0 Datensätze aus
1048576000 bytes transferred in 503,240246 seconds (2083649 bytes/sec)
real 8m23.272s
user 0m0.014s
sys 5m29.195s
>
> Vielleicht sollte ich erstmal eine Scheibe von einem anderen Hersteller
> testen!?
einmal das, dann evtl. mal mit cd-ide versuchen.
Mein System ist in der Zeit wunderbar reaktiv und verhält sich für normale
Office-Sachen Textschreiben / Mail/News lesen+schreiben / WWW wie sonst auch.
und die Zeiten decken sich auch mit einem Zitat aus einer News mit einem Zitat
der c't, das ich mal gefunden habe:
<quote>
Hmm, Verifying ist automatisch dabei. Ich zitiere aus der c't 18/2003
S.124 ff.
"Auf die nominale DVD-RAM-Geschwindigkeit von 3X kommt der LG-Brenner
nur beim Lesen. Die Schreibgeschwindigkeit wird durch ein
automatisches Verify quasi halbiert.Effektiv benötigt man so mit UDF
zehn und mit FAT32 sogar 15 Minuten, um 1 GByte an Daten zu schreiben.
Die automatische Schreibüberprüfung lässt sich selbst mit einer
separaten Brennsoftware nicht umgehen - dies soll aber mit einer
späteren Firmware-Revision möglich werden."
</quote>
Gruss Andreas
> Am Donnerstag, 23. September 2004 22:01 schrieb Manfred Tremmel:
> > Hast Du Vergleichswerte, z.B. mit der 1 GB Datei?
> Zwecklos, da bekomme ich einfach keine reproduzierbaren und
> representativen Zeiten hin.
seltsam, auch nciht mit 2.6?
> Ich habe die gleiche 1GB Datei erneut auf
> die DVD-RAM mit ext2 geschrieben (gebootet mit SuSE-default-Kernel):
> ueber 12 Minuten! Dabei war der Desktop kaum zu benutzen (dauerndes
> Ruckeln, keine oder sehr spaete Reaktionen auf Maus- oder
> Tastaturaktionen).
>
> Da ich etwas von einem Kernel-Problem gelesen habe, das angeblich im
> 2.6er behoben ist habe ich einen 2.6er gebootet. Das Ruckeln war weg,
> das Kopieren der 1GB Datei (auf ein ext2 FS) dauerte aber nun weit
> ueber 20 Minuten!
ihc hab hier ein Debiansystem mit einem DVD-Ram (irgendsoein LG-Teil) mit
Kernel 2.6.7 und _ohne_ ide-scsi da habe ich vor einiger zeit mal Tests mit
dem ext2-FS gemacht:
andreas@einstein:~/tmp$ time dd if=/dev/urandom of=testfile bs=1024k
count=1000
1000+0 Datensätze ein
1000+0 Datensätze aus
1048576000 bytes transferred in 339,946311 seconds (3084534 bytes/sec)
real 5m39.992s
user 0m0.010s
sys 5m25.455s
1/ Filesystem mit Blockgröße von 2048 anlegen:
einstein:/media# time mke2fs -b 2048 -m 0 /dev/hdd
[...]
real 2m54.545s
user 0m0.019s
sys 0m0.199s
2/ Testdatei auf FS kopieren:
andreas@einstein:~/tmp$ time cp testfile /media/dvdram/
real 14m1.718s
user 0m0.307s
sys 0m5.083s
in diesem Zeit-Fenster ist das mehrfach reproduzierbar.
3/Filesystem mit blockgröße 4096 anlegen:
einstein:/media# time mke2fs -b 4096 -m 0 /dev/hdd
mke2fs 1.35 (28-Feb-2004)
[...]
real 1m37.748s
user 0m0.010s
sys 0m0.204s
4/ und datei kopieren
andreas@einstein:~/tmp$ time cp testfile /media/dvdram/
real 11m56.132s
user 0m0.319s
sys 0m4.486s
die blockgröße macht sich bei einer entsprechenden Datei bemerkbar :)
hier fehlen mir noch Tests mit 'realen' Dateigrößen Verteilungen aber an sich
6/ ok, wie macht sich udf?
einstein:/media# time mkudffs --media-type=dvdram /dev/hdd
start=0, blocks=16, type=RESERVED
start=16, blocks=3, type=VRS
start=19, blocks=237, type=USPACE
start=256, blocks=1, type=ANCHOR
start=257, blocks=16, type=PVDS
start=273, blocks=1, type=LVID
start=274, blocks=2236173, type=PSPACE
start=2236447, blocks=1, type=ANCHOR
start=2236448, blocks=239, type=USPACE
start=2236687, blocks=16, type=RVDS
start=2236703, blocks=1, type=ANCHOR
real 0m0.833s
user 0m0.002s
sys 0m0.008s
einstein:/media#
7/ Kopieren der Random-Datei:
andreas@einstein:~/tmp$ time cp testfile /media/dvdram/
real 11m29.087s
user 0m0.357s
sys 0m5.404s
8/ zum schluss hab ich nochmal die gleiche Zahl an Bytes aus /dev/zero bzw
aus /dev/urandom direkt auf ein Medium geschrieben:
einstein:/media# time dd if=/dev/zero of=/dev/hdd bs=1024k count=1000
1000+0 Datensätze ein
1000+0 Datensätze aus
1048576000 bytes transferred in 477,818662 seconds (2194506 bytes/sec)
real 7m57.856s
user 0m0.013s
sys 0m2.926s
einstein:/media# time dd if=/dev/urandom of=/dev/hdd bs=1024k count=1000
1000+0 Datensätze ein
1000+0 Datensätze aus
1048576000 bytes transferred in 503,240246 seconds (2083649 bytes/sec)
real 8m23.272s
user 0m0.014s
sys 5m29.195s
>
> Vielleicht sollte ich erstmal eine Scheibe von einem anderen Hersteller
> testen!?
einmal das, dann evtl. mal mit cd-ide versuchen.
Mein System ist in der Zeit wunderbar reaktiv und verhält sich für normale
Office-Sachen Textschreiben / Mail/News lesen+schreiben / WWW wie sonst auch.
und die Zeiten decken sich auch mit einem Zitat aus einer News mit einem Zitat
der c't, das ich mal gefunden habe:
<quote>
Hmm, Verifying ist automatisch dabei. Ich zitiere aus der c't 18/2003
S.124 ff.
"Auf die nominale DVD-RAM-Geschwindigkeit von 3X kommt der LG-Brenner
nur beim Lesen. Die Schreibgeschwindigkeit wird durch ein
automatisches Verify quasi halbiert.Effektiv benötigt man so mit UDF
zehn und mit FAT32 sogar 15 Minuten, um 1 GByte an Daten zu schreiben.
Die automatische Schreibüberprüfung lässt sich selbst mit einer
separaten Brennsoftware nicht umgehen - dies soll aber mit einer
späteren Firmware-Revision möglich werden."
</quote>
Gruss Andreas
| < Previous | Next > |