* Volker Kuhlmann wrote on Sat, Dec 30, 2006 at 08:01 +1300:
(scsi-emulation)
Auf Kernel 2.6 bitte abschalten.
Macht der SATA-Treiber. Wie kriege ich das aus?
Um ca. 19:30 hatte ich 400 MB auf der DVDRAM (ext2 filesystem, weil UDF anscheinend unbrauchbar implementiert ist). Seit dem schreibt rsync, hat jetzt 23:15 2.5 GB drauf. Also ca. 2 GB in dreieinhalb Stunden, 571 MB pro Stunde, 10 MB pro Minute oder 150 KB pro Sekunde. Was lustigerweise CD-ROM 1 fach ist :-)
Woher kommt Dein "udf anscheinend unbrauchbar"? Verglichen Mit Redmond mag das stimmen, verglichen mit ext2 in Punkto Performance sicher nicht.
Ich bekam nach einem rsync Probleme wie "cannot stat file xyz: permission denied" (laut ls gabs xyz jeweils nicht). Umlaute waren scheinbar kaputt (dachte, genau das wäre eine Stärke von UDF und diesem teuren UTF8 Kram). Wenn ich zweimal rsync durchlaufen lasse, erwarte ich, dass "nix" passiert. "permission denied" und sowas war mir suspekt. Ich bilde mir ein, von unzureichendem UDF Support gelesen zu haben. Also hab ich ein ext2 drauf gemacht.
Unbedingt die DVDRAM mit noatime mounten, sonst kriegst Du Kaffeinvergiftung.
Ja, hab ich (hatte ich aber auch in meiner Mail gesagt).
Ich erwarte aber 1,9 - 2.0 MB/sec, also grob die zehnfache Geschwindigkeit.
Das ist beim linearen Schreiben der Fall. Bei Dateisystemoperationen ist da viel random access dabei, den udf zwar zu reduzieren versucht, wobei es aber auf Linux nicht unbedingt sehr erfolgreich ist. Besser als ext2 sollte es aber schon sein.
Ich habe als Schnelltest neulich bekommen: Daten, als tar file (unkomprimiert!): 75MB, davon d 121, f 775, l 61. Brenner 'DVDRAM GSA-H12N ', SUSE 10.2. Schreibzeit für cp -a: 9 Sekunden. In den Blockbuffer... Schreibzeit für sync: 327 Sekunden. Also 220kbyte/s. UDF.
Nicht wirklich überzeugend. Da alle Daten komplett in den Blockbuffer paßten, wäre katastrophal ein besseres Wort. Vielleicht gehts ja besser, wenn man ausschließlich große (>>MB) Dateien schreibt.
sync wird ja wohl sequentiell syncen! Ich kann mich erinnern, dass Netware 3.11 schon "elevator seeking" konnte. Das war vor ca. 100 Jahren.... :) Nee, mal ernsthaft: dass soll doch jetzt nicht etwa heissen, dass 100-200 KB / sec, also 5% Performance, "normal" und akzeptabel seien?!
Ich wollte gucken, ob DMA an ist. Wie mache ich das?
hdparm /dev/hdX (auch mit ide-scsi)
Was ist X? a-d sicher nicht. e auch nicht (probiert, siehe meine andere Mail). dmesg sagt mir nichts dazu.
Udev oder wasweißich hat einen Fehler und vergessen, den Geräteeintrag anzulegen. man mknod, die major/minor Nummern siehst Du auf einer anderen Kiste nach. Oder besser ide-scsi in die Tonne packen, das ist mit 2.6 veraltet.
Ja, sorry. ide-scsi wird wohl auch gar nicht verwendet. Die SCSI-Emulation macht wohl der SATA Treiber.
Wenn ich das Brennergeräusch richtig deute, dreht er immer nur mal ganz kurz hoch, so als ob die Daten einfach so lahm ankämen - weil z.B. kein DMA an ist.
Ohne DMA wäre die CPU auf 100%. Ist sie das? Oder dreht der Brenner runter, weil er ständig die Köpfe schiebt?
Hatte das mal bei Platten ohne 100%... naja. Weiss nicht, kann "Kopfschieben" sein, würde mich aber extrem enttäuschen, wenn ein linux sync so dämlich wäre (wo man ja heute RAID5 rechunken kann!). Dann frage ich zusätlich mal anders: hat jemand akzeptable DVD RAM Performance (also mehr als 50% der theoretischen)? Kann doch nicht sein, dass man da mit 100 KB / sec rumgurken soll! Sind ja fast Floppy-Geschwindigkeiten ;) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org