Hi, SUSE LINUX 10.0 (i586) OSS, Linux diva 2.6.13-15-smp #1 SMP Tue Sep 13 14:56:15 UTC 2005 i686 athlon i386 GNU/Linux Brenner: Vendor: HL-DT-ST Model: DVDRAM GSA-4120B Rev: A115 (scsi-emulation) 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 :-) Ich erwarte aber 1,9 - 2.0 MB/sec, also grob die zehnfache Geschwindigkeit. Ich wollte gucken, ob DMA an ist. Wie mache ich das? Ich habe kein /dev/hd? Gerät für den Brenner, nur die SCSI-Geräte. Früher gabs das /dev/hdb oder was man da hatte immer noch, da konnte man dann hdparm aufrufen. Das hat google auch oft empfohlen. (BTW, unter W2K gehen DVD-Rs mit 5 MB/sec, Hardware sollte also OK sein). 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. DVD-R schreiben über dvdrecord/growisofs (oder wie das heisst) ist deutlich schneller (DVD in 10 Minuten oder so, also wie erwartet, alles fein). Wie kann ich das näher untersuchen? oki, Steffen Paar Zusatzinfos folgen. in fstab hab ich: /dev/sr0 /media/dvdram4bak ext2 noauto,rw,user,nosuid,nodev,exec,noatime 0 0 syslog (/var/log/messages) zeigt nichts auffälliges. Noch paar Infos aus dmesg. hda und hdc sind Platten, die an den beiden onboard IDE Controllern als RAID laufen. Der Brenner ist an der PATA Schnittstelle des "SATA"-Controllers. Wenn ich nicht ganz irre ist das ein "VT6421 IDE RAID Controller", der 2 SATA und 1 PATA hat. An letzerem hängt der Brenner (Abit AX8 Board). dmesg Auszug: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx SCSI subsystem initialized libata version 1.12 loaded. sata_via: module not supported by Novell, setting U taint flag. sata_via version 1.1 ACPI: PCI Interrupt 0000:00:0c.0[A] -> GSI 20 (level, low) -> IRQ 193 PCI: Via IRQ fixup for 0000:00:0c.0, from 10 to 1 sata_via(0000:00:0c.0): routed to hard irq line 1 ata1: PATA max UDMA/133 cmd 0xFD00 ctl 0xFD0A bmdma 0xF900 irq 193 ata2: PATA max UDMA/133 cmd 0xFC00 ctl 0xFC0A bmdma 0xF908 irq 193 ata3: PATA max UDMA/133 cmd 0xFB00 ctl 0xFB0A bmdma 0xF910 irq 193 input: AT Translated Set 2 keyboard on isa0060/serio0 ATA: abnormal status 0x7F on port 0xFD07 ata1: disabling port scsi0 : sata_via ATA: abnormal status 0x7F on port 0xFC07 ata2: disabling port scsi1 : sata_via ata3: dev 0 cfg 49:0f00 82:421c 83:0000 84:0000 85:0000 86:0000 87:0000 88:0407 ata3: dev 0 ATAPI, max UDMA/33 ata3: dev 0 configured for UDMA/33 scsi2 : sata_via Vendor: HL-DT-ST Model: DVDRAM GSA-4120B Rev: A115 Type: CD-ROM ANSI SCSI revision: 05 sr0: scsi3-mmc drive: 23x/23x writer dvd-ram cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 Attached scsi CD-ROM sr0 at scsi2, channel 0, id 0, lun 0 ACPI-0212: *** Warning: Device is not power manageable ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 20 ACPI: PCI Interrupt 0000:00:0f.0[B] -> Link [ALKA] -> GSI 20 (level, low) -> IRQ 193 PCI: Via IRQ fixup for 0000:00:0f.0, from 11 to 1 sata_via(0000:00:0f.0): routed to hard irq line 1 Attached scsi generic sg0 at scsi2, channel 0, id 0, lun 0, type 5 ata4: SATA max UDMA/133 cmd 0xF800 ctl 0xF702 bmdma 0xF400 irq 193 ata5: SATA max UDMA/133 cmd 0xF600 ctl 0xF502 bmdma 0xF408 irq 193 ATA: abnormal status 0x7F on port 0xF807 scsi3 : sata_via ATA: abnormal status 0x7F on port 0xF607 scsi4 : sata_via VP_IDE: IDE controller at PCI slot 0000:00:0f.1 ACPI-0212: *** Warning: Device is not power manageable ACPI: PCI Interrupt 0000:00:0f.1[A] -> Link [ALKA] -> GSI 20 (level, low) -> IRQ 193 PCI: Via IRQ fixup for 0000:00:0f.1, from 255 to 1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1 ide0: BM-DMA at 0xf300-0xf307, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xf308-0xf30f, BIOS settings: hdc:DMA, hdd:pio Probing IDE interface ide0... hda: Maxtor 6Y120L0, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: max request size: 128KiB hda: 240121728 sectors (122942 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(133) hda: cache flushes supported hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 > Probing IDE interface ide1... hdc: Maxtor 6Y120L0, ATA DISK drive ide1 at 0x170-0x177,0x376 on irq 15 hdc: max request size: 128KiB hdc: 240121728 sectors (122942 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(133) hdc: cache flushes supported hdc: hdc1 hdc2 hdc3 hdc4 < hdc5 hdc6 hdc7 > ACPI: CPU0 (power states: C1[C1]) ACPI: CPU1 (power states: C1[C1]) md: raid1 personality registered as nr 3 -- 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
Hallo Steffen, Am Don, 28 Dez 2006, Steffen Dettmer schrieb:
SUSE LINUX 10.0 (i586) OSS, Linux diva 2.6.13-15-smp #1 SMP Tue Sep 13 14:56:15 UTC 2005 i686 athlon
SuSE Kernel?
Vendor: HL-DT-ST Model: DVDRAM GSA-4120B Rev: A115 (scsi-emulation) [..] Ich wollte gucken, ob DMA an ist. Wie mache ich das?
sdparm (ob das bei 10.0 schon dabei ist?), hdparm, cat /proc/ide/hdX/settings (sofern vorhanden)... Verwendest du ide-scsi? Und wenn ja: Mit Absicht?
Ich habe kein /dev/hd? Gerät für den Brenner, nur die SCSI-Geräte. Früher gabs das /dev/hdb oder was man da hatte immer noch, da konnte man dann hdparm aufrufen. Das hat google auch oft empfohlen. (BTW, unter W2K gehen DVD-Rs mit 5 MB/sec, Hardware sollte also OK sein).
/dev/hdX kannst du zur Not per Hand anlegen. $ ls -l /dev/hd[a-d] brw-r----- 1 root disk 3, 0 Jul 23 1999 /dev/hda brw-r----- 1 root disk 3, 64 Jul 23 1999 /dev/hdb brw-r----- 1 root disk 22, 0 Jul 23 1999 /dev/hdc brw-r----- 1 root disk 22, 64 Jul 23 1999 /dev/hdd => # mknod /dev/hda b 3 0; mknod /dev/hdb b 3 64; \ mknod /dev/hdc b 22 0; mknod /dev/hdd b 22 64
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. [..] in fstab hab ich: /dev/sr0 /media/dvdram4bak ext2 noauto,rw,user,nosuid,nodev,exec,noatime 0 0 ^^ Eigentlich sind /dev/srX ( == /dev/scdX) cdrom-devices, also per se "read-only"... Ich kenn mich mit DVD-RAM nicht aus, kann sein, dass das Device da "missbraucht" wird.
hda und hdc sind Platten, die an den beiden onboard IDE Controllern als RAID laufen. Der Brenner ist an der PATA Schnittstelle des "SATA"-Controllers. Wenn ich nicht ganz irre ist das ein "VT6421 IDE RAID Controller", der 2 SATA und 1 PATA hat. An letzerem hängt der Brenner (Abit AX8 Board). [..] scsi1 : sata_via ata3: dev 0 cfg 49:0f00 82:421c 83:0000 84:0000 85:0000 86:0000 87:0000 88:0407 ata3: dev 0 ATAPI, max UDMA/33 ata3: dev 0 configured for UDMA/33 scsi2 : sata_via Vendor: HL-DT-ST Model: DVDRAM GSA-4120B Rev: A115 Type: CD-ROM ANSI SCSI revision: 05 sr0: scsi3-mmc drive: 23x/23x writer dvd-ram cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 Attached scsi CD-ROM sr0 at scsi2, channel 0, id 0, lun 0
Das sieht eigentlich nach SATA aus... Wird zumindest so eingehaengt. Also wohl kein ide-scsi, odr? An was für Kabeln/Steckern hängt das Teil denn? Und das sieht nach UDMA/33 aus, das sollte schnell genug sein. [..]
VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1 ide0: BM-DMA at 0xf300-0xf307, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xf308-0xf30f, BIOS settings: hdc:DMA, hdd:pio Probing IDE interface ide0... hda: Maxtor 6Y120L0, ATA DISK drive [..] hdc: Maxtor 6Y120L0, ATA DISK drive
Das ist wohl ok (siehe aber 'hdparm -i /dev/hd{a,c}'). Falls sich sonst nix ergibt ist evtl. ein Kernelupdate nen Versuch wert, denn die Via-Chipsätze sind etwas doof, kann sein, dass das ein Bug ist. Kruschtel ggfs. mal in den Changelogs des (SuSE-) Kernels oder gleich in sata_via.[ch]? -dnh -- $max = [$a => $b] -> [ $a <= $b ]; ## Simon Cozens -- 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
Hi David! * David Haller wrote on Fri, Dec 29, 2006 at 06:34 +0100:
Am Don, 28 Dez 2006, Steffen Dettmer schrieb:
SUSE LINUX 10.0 (i586) OSS, Linux diva 2.6.13-15-smp #1 SMP Tue Sep 13 14:56:15 UTC 2005 i686 athlon
SuSE Kernel?
Ja, bis auf den VT6421 Treiber (module, ich glauch via_sata.o oder so). Das vom Kernel kann den PATA nicht. Im Internet fand ich einen Patch.
Vendor: HL-DT-ST Model: DVDRAM GSA-4120B Rev: A115 (scsi-emulation) [..] Ich wollte gucken, ob DMA an ist. Wie mache ich das?
sdparm (ob das bei 10.0 schon dabei ist?),
Danke, apt hats gefunden. Aber mags nicht saugen. Na ja, wäre auch ein Wunder, wenn bei mir mal was funktioniert. wget und rpm gingen. Find in sdparm aber nix von DMA (was mich auch nicht wirklich überrascht.
hdparm,
Tja, aber auf welches Device?
cat /proc/ide/hdX/settings (sofern vorhanden)...
Da finde ich hda und hdc, meine beiden Platten, aber nicht mein DVDRAM (was ja am PATA Port des SATA Controllers hängt).
Verwendest du ide-scsi? Und wenn ja: Mit Absicht?
ich /glaube/ nicht. Die SCSI Emulation (oder wie das heisst) wird scheinbar vom via_sata gemacht: ata3: dev 0 cfg 49:0f00 82:421c 83:0000 84:0000 85:0000 86:0000 87:0000 88:0407 ata3: dev 0 ATAPI, max UDMA/33 ata3: dev 0 configured for UDMA/33 scsi2 : sata_via Vendor: HL-DT-ST Model: DVDRAM GSA-4120B Rev: A115 Type: CD-ROM ANSI SCSI revision: 05 sr0: scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 Attached scsi CD-ROM sr0 at scsi2, channel 0, id 0, lun 0 ACPI-0212: *** Warning: Device is not power manageable
/dev/hdX kannst du zur Not per Hand anlegen.
Ja, aber davon existiert das device ja noch lange nicht...
=> # mknod /dev/hda b 3 0; mknod /dev/hdb b 3 64; \ mknod /dev/hdc b 22 0; mknod /dev/hdd b 22 64
Wenn, dann wäre der dritte PATA Controller hde, oder? Ich hab es sogar probiert: diva:~ # mknod /dev/hde b 33 0 diva:~ # l /dev/hde brw-r--r-- 1 root root 33, 0 Dec 29 18:43 /dev/hde diva:~ # hdparm /dev/hde /dev/hde: No such device or address
in fstab hab ich: /dev/sr0 /media/dvdram4bak ext2 noauto,rw,user,nosuid,nodev,exec,noatime 0 0 ^^ Eigentlich sind /dev/srX ( == /dev/scdX) cdrom-devices, also per se "read-only"... Ich kenn mich mit DVD-RAM nicht aus, kann sein, dass das Device da "missbraucht" wird.
sdparm macht für /dev/sg0 die gleichen Angaben, aber: diva:/tmp/public/linkraid/!Backup # mount /dev/sg0 -o nosuid,nodev,exec,noatime /media/dvdram4bak/ mount: /dev/sg0 is not a block device ich kanns nicht mounten. sr0 geht so.
ata3: dev 0 ATAPI, max UDMA/33 ata3: dev 0 configured for UDMA/33 scsi2 : sata_via Vendor: HL-DT-ST Model: DVDRAM GSA-4120B Rev: A115 Type: CD-ROM ANSI SCSI revision: 05 sr0: scsi3-mmc drive: 23x/23x writer dvd-ram cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 Attached scsi CD-ROM sr0 at scsi2, channel 0, id 0, lun 0
Das sieht eigentlich nach SATA aus... Wird zumindest so eingehaengt. Also wohl kein ide-scsi, odr? An was für Kabeln/Steckern hängt das Teil denn?
An einem ollen klassischem IDE Flachbandkabel am 3. PATA Port auf dem Mainboar; das ist der eines onboard VT6421 Controllers (eigentlich SATA, aber auch auch einen PATA Port). Der SATA Treiber macht den mit, ja.
Und das sieht nach UDMA/33 aus, das sollte schnell genug sein.
Ja, muss ja eigentlich auch, wenn DVD-R schnell ist, kann ja das IDE nicht wissen, was für'n Medium drin steckt :)
hdc: Maxtor 6Y120L0, ATA DISK drive
Das ist wohl ok (siehe aber 'hdparm -i /dev/hd{a,c}').
Ja, das ist OK: diva:~ # hdparm -t /dev/tmp/tmp Timing buffered disk reads: 316 MB in 3.01 seconds = 104.91 MB/sec da kann man nicht meckern. md5sum auf CD-R Image in sieben Sekunden, geht schon :) Danke für Deine Tips, aber haben wohl nicht geholfen. Na doch, jetzt bin ich mir recht sicher, dass es /nicht/ am DMA liegt... Ach so, ich hab verschiedene Medien probiert (was aber nix zu sagen hat, vielleicht ist das gleiche relabeled media drin lol). Weitere Ideen? 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
Brenner: Vendor: HL-DT-ST Model: DVDRAM GSA-4120B Rev: A115
Sollte unter Linux problemlos gehen.
(scsi-emulation)
Auf Kernel 2.6 bitte abschalten.
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. Unbedingt die DVDRAM mit noatime mounten, sonst kriegst Du Kaffeinvergiftung.
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.
Ich wollte gucken, ob DMA an ist. Wie mache ich das?
hdparm /dev/hdX (auch mit ide-scsi)
Ich habe kein /dev/hd? Gerät für den Brenner, nur die SCSI-Geräte.
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.
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?
DVD-R schreiben über dvdrecord/growisofs (oder wie das heisst)
growisofs
ist deutlich schneller (DVD in 10 Minuten oder so, also wie erwartet, alles fein).
Linear schreiben geht immer mit maximaler Geschwindigkeit. Genau wie mit Band... Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- 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
* 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
Ich benutze DVD-Ram schon seit Jahren mit UDF und bin recht zufrieden. Bei großen tar Files ist die Geschwindigkeit einwandfrei. Hardware: sascha@datiscum5:~> cat /proc/ide/hda/model HL-DT-ST DVDRAM GSA-4160B Hier mal ein paar Werte von mir: Ordner INTERNET hat eine Größe von 852,9 MByte und enthält 2913 Dateien und 309 Unterordner. sascha@datiscum5:/net> time cp -R INTERNET/ /media/LinuxUDF/ real 0m22.914s user 0m0.076s sys 0m4.568s sascha@datiscum5:/net> time sync real 16m27.494s user 0m0.000s sys 0m1.276s ges. 1010 sekunden für 852,9 MByte 843KByte/s -- naja viele Dateien Eine große Datei 878,9 MByte sascha@datiscum5:/net> time cp /home/sascha/DVD_RamTest922MB.dat /media/LinuxUDF/ time sync real 1m46.437s user 0m0.044s sys 0m4.256s sascha@datiscum5:/net> time sync real 6m13.328s user 0m0.000s sys 0m1.368s ges. 480 sekunden für 878,9 MByte 1,8 MByte/s -- Das ist ordentlich. Also große Backupfiles lassen sich super kopieren. Gruß, -- 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
(scsi-emulation)
Auf Kernel 2.6 bitte abschalten.
Macht der SATA-Treiber. Wie kriege ich das aus?
Du hast einen SATA Brenner? Gibts sowas überhaupt? Dann hast Du in dem Punkt hier Pech gehabt. Die IDE-Stecker auf Mobos sind ideal für optische Laufwerke... ;)
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.
Hmm. Das hat was mit character sets zu tun. UDF ist, fast schon per definition, utf8. SUSE ist aber auch schon länger utf8, aber das kann man abschalten.
Also hab ich ein ext2 drauf gemacht.
Hm. Das ist überhaupt nicht für extrem langsame Medien gemacht (verglichen mit Platte), oder für Medien mit begrenzter Anzahl von Schreibzugriffen für jeden Block. Viel Glück ;)
sync wird ja wohl sequentiell syncen!
Woher weißt Du das? Irgendwoher muß die erbärmlich Performance ja kommen.
Ich wollte gucken, ob DMA an ist. Wie mache ich das?
hdparm /dev/hdX (auch mit ide-scsi)
Was ist X?
0, 1, 2 oder 3, jenachdem an welchem Stecker/Kabel die Platte halt hängt. Für SATA Geräte weiß ich aber auch nicht, außer /dev/sdX gibt es ja nichts, bzw /dev/srX bei Optischen.
Dann frage ich zusätlich mal anders: hat jemand akzeptable DVD RAM Performance (also mehr als 50% der theoretischen)?
Gute Frage. Da es offensichtlich geht, würde mich interessieren, was man drehen muß.
Kann doch nicht sein, dass man da mit 100 KB / sec rumgurken soll!
Ack^2 Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- 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
* Volker Kuhlmann wrote on Sun, Dec 31, 2006 at 18:10 +1300:
(scsi-emulation)
Auf Kernel 2.6 bitte abschalten.
Macht der SATA-Treiber. Wie kriege ich das aus?
Du hast einen SATA Brenner?
Nein, einen PATA/ATAPI. (Nein, immer noch kein SATA. Hab ich doch schon mehrmals geschrieben :))
Gibts sowas überhaupt?
Ja, gibt es, z.B. hier: http://www.alternate.de/html/shop/productListing4C.html?cat1=061&cat2=054&cat3=000&treeName=HARDWARE&Level1=Laufwerke&Level2=DVD-Brenner&Level3=Serial+ATA&
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.
Hmm. Das hat was mit character sets zu tun. UDF ist, fast schon per definition, utf8. SUSE ist aber auch schon länger utf8, aber das kann man abschalten.
Wie auch immer, es funktioniert anscheinend nicht. Mein (anders) Test UDF Medium ist inzwischen (auch) kaputt. Lixux kann einige Files noch (korrekt) lesen, W2K weigert sich total, es zu lesen. Na ja. Überzeugt mich *überhaupt nicht*. Ich halte es sogar für eine Katastrophe. Ich mag Filesysteme, wo ich das runterlesen kann, was ich raufgeschrieben habe :-) Finde im Internet leider nicht wirklich was über die "Stabilität" von UDF / UTF8. Ein Sourceforgeprojekt schreibt "produktion/stable", aber sind anscheinend noch kernel patches? Hat jemand einen Link zur Hand?
sync wird ja wohl sequentiell syncen!
Woher weißt Du das? Irgendwoher muß die erbärmlich Performance ja kommen.
Ich weiss es nicht, sondern vermute/erwarte es; wie gesagt, Netware 3.11 konnte schon "elevator seeking", sollte ja heute Standard sein.
Ich wollte gucken, ob DMA an ist. Wie mache ich das?
hdparm /dev/hdX (auch mit ide-scsi)
Was ist X?
0, 1, 2 oder 3,
Das ist falsch, aber ich fragte sowieso nach einem konkreten Wert. Ich weiss, dass Buchstaben "eingesetzt" werden müssen, aber halt nicht welcher, da ich nur /dev/hda und /dev/hdc habe - aber kein /dev/hde oder sowas.
jenachdem an welchem Stecker/Kabel die Platte halt hängt. Für SATA Geräte weiß ich aber auch nicht, außer /dev/sdX gibt es ja nichts, bzw /dev/srX bei Optischen.
Da funktioniert bei mir hdparm aber nicht drauf (bzw. zeigt nicht an, ob DMA aktiv ist, weil der ioctrl hier nicht verfügbar ist). Aber wie gesagt, inzwischen bin ich mir recht sicher, dass es nicht am DMA liegt... Nur woran dann... mmmm... 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
(Nein, immer noch kein SATA. Hab ich doch schon mehrmals geschrieben :))
Jetzt ist das klar wie Kloßbrühe. Warum kannst Du mit einem PATA Brenner ide-scsi nicht loswerden?
Wie auch immer, es funktioniert anscheinend nicht. Mein (anders) Test UDF Medium ist inzwischen (auch) kaputt. Lixux kann einige Files noch (korrekt) lesen, W2K weigert sich total, es zu lesen. Na ja.
Unterschiede in der Dateisystemimplementierung?
Überzeugt mich *überhaupt nicht*. Ich halte es sogar für eine Katastrophe.
Ich mag Filesysteme, wo ich das runterlesen kann, was ich raufgeschrieben habe :-)
Ack
hdparm /dev/hdX (auch mit ide-scsi)
Was ist X?
0, 1, 2 oder 3,
oops, a, b, c, d meinte ich.
Ich weiss, dass Buchstaben "eingesetzt" werden müssen, aber halt nicht welcher, da ich nur /dev/hda und /dev/hdc habe - aber kein /dev/hde oder sowas.
more /proc/ide/hd?/model zeigt Dir die Zuordnung an. Bei PATA Brennern mit Flachbandkabel am Mobo ist Gerät und Datenträger /dev/hd?. Mit ide-scsi sinds /dev/hd? für das Gerät und /dev/sr? für den Datenträger wenn ich mich richtig erinnere (der Fummel ist schon Jahre her). SATA Festplatten sind /dev/sd?, SATA Brenner vermutlich auch (und dann wieder mit Datenträger /dev/sr?), aber ich habe selber noch keinen gesehen. Ich habe bisher auch ext2 auf DVD backups genommen, aber nie r/w. Das geht bei mir immer so: writecd --blockread /dev/dvd >image.ext2 mount -orw,loop image.ext2 .. [Änderungen auf .. durchführen] cp-ext2 .. new.ext2 mount new.ext2 ... cp-sort .. ... umount image.ext2 new.ext2 growisofs -Z new.ext2 Du findest alles in den scriptutils. Der cp- Schritt ist nach größeren Änderung notwendig und beschleunigt den späteren Lesezugriff von der Scheibe. So wie ich das sehe, werden Alternativen erst interessant, wenn sie deutlich schneller und genauso zuverlässig sind. Ich halte immer noch meine Augen nach dem "schneller" auf, bis jetzt ohne Erfolg. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- 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
Hallo, Am Die, 02 Jan 2007, Volker Kuhlmann schrieb: [Lass doch bitte den Vorredner leben]
Wie auch immer, es funktioniert anscheinend nicht. Mein (anders) Test UDF Medium ist inzwischen (auch) kaputt. Lixux kann einige Files noch (korrekt) lesen, W2K weigert sich total, es zu lesen. Na ja.
Unterschiede in der Dateisystemimplementierung?
Bei Windows muss man IIRC die UDF Treiber nachinstallieren. -dnh -- Why do you focus so much on _new_ technology? -- New is better. Is nothink old that is better than new. -- Yes there is. -- Da? Namink one then. -- The Original Pentium versus counting on your fingers. -- Da. Da. "Don't divide. Intel inside" [Sid & Pitr in userfriendly] -- 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
(OT: W2K DVDRAM) Erstmal danke für all eure Hilfe! * Der Vorredner[1] wrote on Tue, Jan 02, 2007 at 20:48 +0100:
[Lass doch bitte den Vorredner leben]
Wie auch immer, es funktioniert anscheinend nicht. Mein (anders) Test UDF Medium ist inzwischen (auch) kaputt. Lixux kann einige Files noch (korrekt) lesen, W2K weigert sich total, es zu lesen. Na ja.
Unterschiede in der Dateisystemimplementierung?
Bei Windows muss man IIRC die UDF Treiber nachinstallieren.
Ja, bei Win2K sogar um UDF 2.0 lesen zu können. XP kann die so lesen,
aber beide können nicht schreiben. Viele verwenden wohl ein "Nero InCD",
ist wohl so ein Treiber (?), aber der ist wohl nicht frei (?) und wurde
im Internet auch kritisiert. Dann gibts noch so "dvdram.sys" basierte
Treiber.
Falls das mal jemand braucht (DVDRAM UDF 2.0 Schreiben unter W2K):
Ich glaub ich hab http://download.czechcomputer.cz/LG/ genommen. In dem
rar ist ein setup.exe. Neustarten (ggf. sogar zweimal!). DVD RAM sollte
schon mal lesen können.
Jetzt kommt der Trick (Danke Frank!):
Geräte Manager, CD Laufwerk raussuchen. Eigenschaften öffnen. Treiber
aktualisieren. Treiber aus Liste auswählen. "DVD RAM" auswählen,
installieren.
Am Ende muss wiedermal gebootet werden.
Jetzt gibts plötzlich zusätzlich einen "Wechseldatenträger" (neuen LW
Buchstaben), den W2K nu beschreiben kann.
oki,
Steffen
[1] David Haller
* Volker Kuhlmann wrote on Tue, Jan 02, 2007 at 11:59 +1300:
(Nein, immer noch kein SATA. Hab ich doch schon mehrmals geschrieben :))
Jetzt ist das klar wie Kloßbrühe.
Warum kannst Du mit einem PATA Brenner ide-scsi nicht loswerden?
Ich glaube ja, ich hab es gar nicht (zumindestens ist kein ide-scsi modul in lsmod)
Wie auch immer, es funktioniert anscheinend nicht. Mein (anders) Test UDF Medium ist inzwischen (auch) kaputt. Lixux kann einige Files noch (korrekt) lesen, W2K weigert sich total, es zu lesen. Na ja.
Unterschiede in der Dateisystemimplementierung?
Nein, das lag an den Treibern und einem kaputten Filesystem. Windows hatte wohl Recht, "Linux" hat scheinbar das Filesystem "kaputt gemacht". Das Medium ging bei meinem Bekannten, der mir das als Testreferenz geschrieben hat, auch nicht mehr. Wir haben es da neu formatiert. Zu Windows (2000) schreib ich gleich noch was als Reply auf Davids Mail.
Überzeugt mich *überhaupt nicht*. Ich halte es sogar für eine Katastrophe.
Ich mag Filesysteme, wo ich das runterlesen kann, was ich raufgeschrieben habe :-)
Ack
Diesmal haben wir ein UDF 2 auf das Testmedium gemacht (vorher war 1.weiss nicht mehr). Die 700 MB Testfiles haben erstmal auch keine Umlaute ;) Momentan schreibt Linux mit fast 600 KB/sec, dass ist schon halbsoschnell wie W2K.
hdparm /dev/hdX (auch mit ide-scsi)
more /proc/ide/hd?/model zeigt Dir die Zuordnung an.
Nein, da gibts bei mir nur a und c, meine beiden Platten.
Bei PATA Brennern mit Flachbandkabel am Mobo ist Gerät und Datenträger /dev/hd?. Mit ide-scsi sinds /dev/hd? für das Gerät und /dev/sr? für den Datenträger wenn ich mich richtig erinnere (der Fummel ist schon Jahre her).
Wie gesagt, ich glaub ich hab kein ide-scsi, nur die SCSI-Emulation des SATA-Treibers (der auch das PATA Laufwerk "mittreibt").
SATA Festplatten sind /dev/sd?, SATA Brenner vermutlich auch (und dann wieder mit Datenträger /dev/sr?), aber ich habe selber noch keinen gesehen.
Ich habe den Brenner als /dev/sg0 und /dev/sr0. Wie gesagt, dass kommt wohl, weil der SATA Treiber "seinen" PATA Port "mittreibt". sdparm geht auf /dev/sg0 (hdparm nicht, EPERM jeweils)
Ich habe bisher auch ext2 auf DVD backups genommen, aber nie r/w. Das geht bei mir immer so:
writecd --blockread /dev/dvd >image.ext2 mount -orw,loop image.ext2 ..
".." ist ein Platzhalter?!
[Änderungen auf .. durchführen] cp-ext2 .. new.ext2 mount new.ext2 ... cp-sort .. ... umount image.ext2 new.ext2 growisofs -Z new.ext2
Du findest alles in den scriptutils.
diva:/tmp/images # man scriptutils No manual entry for scriptutils diva:/tmp/images # rpm -q scriptutils package scriptutils is not installed diva:/tmp/images # locate scriptutils Ich find nichtmal die. Braucht man sowas? Wenn ich einfach ein backup in ein image haben will, hab ich bisher einfach ein $ time mkisofs -graft-points -J -r -T -o "$img" /="$dir" gemacht und dass dann gebrannt. Das ging ganz einfach, hab aber gerade vergessen, wie lol achso, hier: $ /usr/bin/cdrecord -v gracetime=2 dev=0,0,0 speed=24 -tao driveropts=burnfree -eject -data -tsize=6766s /tmp/FIXME___cd.iso was auch immer tsize jetzt war... Geht das nicht so einfach (also ohne scriptutils, cp und kram)? Welche Nachteile hat mein Weg?
So wie ich das sehe, werden Alternativen erst interessant, wenn sie deutlich schneller und genauso zuverlässig sind. Ich halte immer noch meine Augen nach dem "schneller" auf, bis jetzt ohne Erfolg.
DVD-R schreiben ist bei mir schnell - aber ja keine Alternative, hatte schon etliche DVD-Rs, die ich nicht mehr lesen konnte. RAMs hab ich nur ne Handvoll, aber das rsync on ext2(noatime) lief bisher (kann dann ruhig drei Stunden laufen. Ich sicher von disk auf raid1 disk, manchmal von da auf anderen PC und rsync auf DVD-RAM. Wenn ich die RAM brauche, haben schon zwei Plattenbackups versagt. Oder es hat gebrannt.). 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
On Thu 04 Jan 2007 10:01:05 NZDT +1300, Steffen Dettmer wrote:
writecd --blockread /dev/dvd >image.ext2 mount -orw,loop image.ext2 ..
".." ist ein Platzhalter?!
Jau, den mount-Befehl wirst Du ja wohl noch kennen ;)
[Änderungen auf .. durchführen] cp-ext2 .. new.ext2 mount new.ext2 ... cp-sort .. ... umount image.ext2 new.ext2 growisofs -Z new.ext2
Du findest alles in den scriptutils.
diva:/tmp/images # man scriptutils No manual entry for scriptutils diva:/tmp/images # rpm -q scriptutils package scriptutils is not installed diva:/tmp/images # locate scriptutils
Ich find nichtmal die.
Auf dem eigenen Computer nach Software zu suchen, die man vielleicht installieren möchte, aber noch nicht installiert hat, führt erwartungsgemäß nicht oft zum Ziel. ;) Google wäre da besser, aber ich nehme Dir die Mühe ab: http://volker.dnsalias.net/soft/rpm/suse10.1/
Braucht man sowas?
Die Frage muß jeder für sich selbst beantworten. Ich nehme die Methode für gebrannte ext2.
$ time mkisofs -graft-points -J -r -T -o "$img" /="$dir" $ /usr/bin/cdrecord -v gracetime=2 dev=0,0,0 speed=24 -tao driveropts=burnfree -eject -data -tsize=6766s /tmp/FIXME___cd.iso
Geht das nicht so einfach (also ohne scriptutils, cp und kram)? Welche Nachteile hat mein Weg?
Das schreibt Dir ein ISO9660. Nachteile: ISO9660 ist immer read-only. Fernerhin kann die Linuximplementierung Hardlinks zwar speichern, aber nicht wieder lesen. Vorteile: getested, zuverlässig, sehr schnelle Lesezugriffe (Verzeichnisse und Daten sind gut sortiert abgelegt - deswegen ist's auch nur read-only).
DVD-R schreiben ist bei mir schnell - aber ja keine Alternative, hatte schon etliche DVD-Rs, die ich nicht mehr lesen konnte.
Dann schreib doch auf RAM. Wenn Du das ganze Dateisystem-Image auf einmal schreibst, geht das auch mit max Geschwindigkeit. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- 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
* Volker Kuhlmann wrote on Fri, Jan 05, 2007 at 00:21 +1300:
On Thu 04 Jan 2007 10:01:05 NZDT +1300, Steffen Dettmer wrote:
Du findest alles in den scriptutils.
diva:/tmp/images # locate scriptutils Ich find nichtmal die.
Auf dem eigenen Computer nach Software zu suchen, die man vielleicht installieren möchte, aber noch nicht installiert hat, führt erwartungsgemäß nicht oft zum Ziel. ;)
:) Dachte mir schon sowas. Also war die Antwort mit anderen Worten ja ca "Da gibt es noch was ganz anders, eine Scriptsammlung namens scriptutils, die ..." usw. Dann findet man es vielleicht in scriptutils :-)
Ahh, Deine Scripte? ^^ Die Scripts sind versions-spezifisch? Kein noarch-RPM, was auch SuSE > 8 läuft (wegen rpm4)? :-)
Braucht man sowas?
Die Frage muß jeder für sich selbst beantworten. Ich nehme die Methode für gebrannte ext2.
Ja klar. Meine Frage meinte eher, was dafür spricht, ext2 zu nehmen (und noch diverse Scripte etc), wenn man ein IS0 mit einem Kommando bauen kann. Hätte was vermutet wie Probleme mit den Rechten, bestimmten Dateinamen (langen, Sonderzeichen), sowas halt.
$ time mkisofs -graft-points -J -r -T -o "$img" /="$dir" $ /usr/bin/cdrecord -v gracetime=2 dev=0,0,0 speed=24 -tao driveropts=burnfree -eject -data -tsize=6766s /tmp/FIXME___cd.iso
Geht das nicht so einfach (also ohne scriptutils, cp und kram)? Welche Nachteile hat mein Weg?
Das schreibt Dir ein ISO9660. Nachteile: ISO9660 ist immer read-only. Fernerhin kann die Linuximplementierung Hardlinks zwar speichern, aber nicht wieder lesen. Vorteile: getested, zuverlässig, sehr schnelle Lesezugriffe (Verzeichnisse und Daten sind gut sortiert abgelegt - deswegen ist's auch nur read-only).
Ja, OK. "getested, zuverlässig, sehr schnelle Lesezugriffe" klingt für mich ziemlich genau nach dem, was ich bei einem DVD-R Backup erwarte ;)
DVD-R schreiben ist bei mir schnell - aber ja keine Alternative, hatte schon etliche DVD-Rs, die ich nicht mehr lesen konnte.
Dann schreib doch auf RAM. Wenn Du das ganze Dateisystem-Image auf einmal schreibst, geht das auch mit max Geschwindigkeit.
Ja, das wäre auch mal ein Test wert, klar, prima Idee! Danke! 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
Ahh, Deine Scripte? ^^ Die Scripts sind versions-spezifisch? Kein noarch-RPM, was auch SuSE > 8 läuft (wegen rpm4)? :-)
Das scriptutils ist noarch. Es läuft auch auf älteren SUSEn, aber --nodeps kann da nötig werden. Die Pakete sind in dem ../suseX.Y/ Verzeichnis entsprechend der Version auf der sie gebaut sind. Üblicherweise laufen sie auch auf älteren und neueren SUSEn, aber das ist mir zum Testen zuviel. Jau da gibt es jetzt den Buildservice, da muß ich mich auch noch reinhängen.
Ja klar. Meine Frage meinte eher, was dafür spricht, ext2 zu nehmen (und noch diverse Scripte etc), wenn man ein IS0 mit einem Kommando bauen kann.
Wie gesagt, Linux-iso9660 kann keine Hardlinks erhalten. Für etliche meiner Sachen ist das ein k.o. Ansonsten kann iso9660 alles - Geräte, Pfeifen, unbegrenzte Verzeichnistiefe + Dateinamen, mit RockRidge aber nur. Das Joliet kannst Du knicken, das ist nur was für 'softies. Ach so, keine erweiterten Attribute, das müßtest Du dann per Skript regeln. Außerdem ist Iso9660 lästig, um ein paar Dateien an verschiedenen Stellen im Baum hinzuzufügen. Das mit den Graftpoints ufert in eine elende Skripterei aus, wenn man in eine bestehende Struktur einfügen will. Oder ändern! Ein neues Verzeichnis einfügen, was bisher noch nicht existiert hat, ist einfach - kommt bei mir aber nie vor. Dafür geht Multisession nur mit iso9660. Es kommt alles drauf an, was man tun will. Keine Methode ist immer besser als die andere. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- 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
* Volker Kuhlmann wrote on Mon, Jan 08, 2007 at 21:13 +1300:
Ja klar. Meine Frage meinte eher, was dafür spricht, ext2 zu nehmen (und noch diverse Scripte etc), wenn man ein IS0 mit einem Kommando bauen kann.
Wie gesagt, Linux-iso9660 kann keine Hardlinks erhalten. Für etliche meiner Sachen ist das ein k.o. Ansonsten kann iso9660 alles - Geräte, Pfeifen, unbegrenzte Verzeichnistiefe + Dateinamen, mit RockRidge aber nur. Das Joliet kannst Du knicken, das ist nur was für 'softies. Ach so, keine erweiterten Attribute, das müßtest Du dann per Skript regeln.
Am besten beides rauf, da kann man notfalls mit benachteiligten / alten Systemen evtl. auch was lesen :) ACLs ist ein wichtiger Punkt. Wenn man sowas hat, muss man sich da schon einen Kopf machen. Einmal, wie man Herr des Chaos wird, das man damit meist anrichtet (wenn man meint, ACLs brauchen zu müssen), und zum anderen, was Backups angeht. Kann so ein tar das überhaupt?
Außerdem ist Iso9660 lästig, um ein paar Dateien an verschiedenen Stellen im Baum hinzuzufügen. Das mit den Graftpoints ufert in eine elende Skripterei aus, wenn man in eine bestehende Struktur einfügen will. Oder ändern!
Ja, das stimmt. Ich sammel die Backups vorher auf Platte und dann hab ich nur ein Verzeichnis, dadurch hab ich hier ein leichtes Leben :) 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
Am Montag, 1. Januar 2007 18:56 schrieb Steffen Dettmer:
* Volker Kuhlmann wrote on Sun, Dec 31, 2006 at 18:10 +1300:
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.
Hmm. Das hat was mit character sets zu tun. UDF ist, fast schon per definition, utf8. SUSE ist aber auch schon länger utf8, aber das kann man abschalten.
Wie auch immer, es funktioniert anscheinend nicht. Mein (anders) Test UDF Medium ist inzwischen (auch) kaputt. Lixux kann einige Files noch (korrekt) lesen, W2K weigert sich total, es zu lesen. Na ja.
Überzeugt mich *überhaupt nicht*. Ich halte es sogar für eine Katastrophe.
Ich mag Filesysteme, wo ich das runterlesen kann, was ich raufgeschrieben habe :-)
Finde im Internet leider nicht wirklich was über die "Stabilität" von UDF / UTF8. Ein Sourceforgeprojekt schreibt "produktion/stable", aber sind anscheinend noch kernel patches?
Hat jemand einen Link zur Hand?
Hallo, ich kann Probleme mit DVD-RAM mit UDF und einer Fehlermeldung wie bei Steffen bestätigen. Zunächst hatte ich den Fehler auf LG-Laufwerke geschoben, weil der Fehler in der Hitze des Sommers bei mir und bei einem Kunden gleichzeitig auftrat. Ein neues Laufwerk erzeugte vor ein paar Tagen den gleichen Fehler. Die Inspektion aller Medien brachte dann auch Fehler auf Medien, die bereits vor einem Jahr erstellt wurden. Der Fehler taucht vermutlich dann auf, wenn Dateien gelöscht wurden. Der Fehler kann an UDF-Dateisystem selbst oder an der Linux-Implementation liegen. Meine ersten Suchen im Netz brachten keine klaren Hinweise. Ich habe inzwischen ein Medium mit ext3 versehen und es mehrfach vollgeschrieben. Bis jetzt gab es keine Fehler und fsck.ext2 -c /dev/sr0 bracht auch keinen Fehler. Nebenbemerkung: Der Bericht des ZDF über die Unzuverlässigkeit von CD und DVD hat mich ins Grübeln gebracht. Wie Zuverlässig sind DVD-RAMs tatsächlich? Auf jeden Fall werde ich Daten parallel auf externe Festplatten sichern. Gruß Heiner -- 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
On Wed 03 Jan 2007 21:18:17 NZDT +1300, Heiner Kuhlmann wrote:
ich kann Probleme mit DVD-RAM mit UDF und einer Fehlermeldung wie bei Steffen bestätigen. Zunächst hatte ich den Fehler auf LG-Laufwerke geschoben, weil der Fehler in der Hitze des Sommers bei mir und bei einem Kunden gleichzeitig auftrat. Ein neues Laufwerk erzeugte vor ein paar Tagen den gleichen Fehler. Die Inspektion aller Medien brachte dann auch Fehler auf Medien, die bereits vor einem Jahr erstellt wurden. Der Fehler taucht vermutlich dann auf, wenn Dateien gelöscht wurden.
Nicht gut.
Der Fehler kann an UDF-Dateisystem selbst oder an der Linux-Implementation liegen.
Was ist denn "UDF Dateisystem selbst"? Wohl eher an der Implementierung...
Der Bericht des ZDF über die Unzuverlässigkeit von CD und DVD hat mich ins Grübeln gebracht. Wie Zuverlässig sind DVD-RAMs tatsächlich?
Wie ich auf einer anderen Liste gelesen habe, sind DVD+-R(W) Konsumerformate, Zuverlässigkeit und Datensicherheit stehen deshalb an Stelle 15. DVDRAM ist schon deutlich älter, und von vornherein auf Archivierung ausgelegt. Da macht wohl der Brenner selbst auch automatisch eine Verfifizierung der geschriebenen Blöcke. Wiederbeschreibbarkeit ist enorm, zB die von DVD+RW ist ja bekanntlich schlecht. Genaueres zu DVDRAM würde mich auch interessieren. Der Rest der Formate ist so wie CD, wobei löschbare Scheiben eine deutlich höhere Ausfallrate als +-R haben. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- 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
Am Mittwoch, 3. Januar 2007 10:33 schrieb Volker Kuhlmann:
On Wed 03 Jan 2007 21:18:17 NZDT +1300, Heiner Kuhlmann wrote:
ich kann Probleme mit DVD-RAM mit UDF und einer Fehlermeldung wie bei Steffen bestätigen. Zunächst hatte ich den Fehler auf LG-Laufwerke geschoben, weil der Fehler in der Hitze des Sommers bei mir und bei einem Kunden gleichzeitig auftrat. Ein neues Laufwerk erzeugte vor ein paar Tagen den gleichen Fehler. Die Inspektion aller Medien brachte dann auch Fehler auf Medien, die bereits vor einem Jahr erstellt wurden. Der Fehler taucht vermutlich dann auf, wenn Dateien gelöscht wurden.
Nicht gut.
Der Fehler kann an UDF-Dateisystem selbst oder an der Linux-Implementation liegen.
Was ist denn "UDF Dateisystem selbst"? Wohl eher an der Implementierung...
Konzept des Dateisystems (was passiert beim Rechner-Absturuz?). Ich vermute es liegt an der Implementierung. Im Internet habe ich eine Frage zu diesem Problem gefunden allerdings ohne Antwort.
Der Bericht des ZDF über die Unzuverlässigkeit von CD und DVD hat mich ins Grübeln gebracht. Wie Zuverlässig sind DVD-RAMs tatsächlich?
Wie ich auf einer anderen Liste gelesen habe, sind DVD+-R(W) Konsumerformate, Zuverlässigkeit und Datensicherheit stehen deshalb an Stelle 15. DVDRAM ist schon deutlich älter, und von vornherein auf Archivierung ausgelegt. Da macht wohl der Brenner selbst auch automatisch eine Verfifizierung der geschriebenen Blöcke. Wiederbeschreibbarkeit ist enorm, zB die von DVD+RW ist ja bekanntlich schlecht. Genaueres zu DVDRAM würde mich auch interessieren. Der Rest der Formate ist so wie CD, wobei löschbare Scheiben eine deutlich höhere Ausfallrate als +-R haben.
Ich verwende DVD-RAM, weil sie sehr zuverlässig sein sollen. Sie sollen bis zu 100000 mal beschreibbar sein. Ich schreibe nur tar-Archive drauf in der Größenordnung von 100. Auf einigen DVD-RAMs wurden Dateien gelöscht. Hier traten die Probleme auf. Meine ältesten DVD-RAMs (auf denen nicht gelöscht wurde) sind über ein Jahr alt und ohne Fehler. Wenn Fehler auftraten waren es immer Fehler im Dateisystem selbst in der Art von (unter root) ls: cannot access /media/MEI_UDF/DVD-RAM_1167184166/home/uml.tgz: Permission denied Ich habe - bis jetzt - keinen Fehler beim Lesen von Datei-Inhalten gehabt. Allerdings kam es zu Problemen, weil sich der umount einer DVD-RAM aufhängte. Ich hatte auch DVD-RAMs, die von dem Brenner nicht mehr angenommen wurden. Meine Vermutung war, dass der Brenner defekt war. Muss ich noch einmal genauer untersuchen. Ich werde eine DVD-RAM mit ext3 einmal quälen: mit etwa 100 Dateien vollschreiben, testen, löschen usw. Bis auf weiteres Heiner -- 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
Hallo, Am Mit, 03 Jan 2007, Heiner Kuhlmann schrieb:
Ich verwende DVD-RAM, weil sie sehr zuverlässig sein sollen. Sie sollen bis zu 100000 mal beschreibbar sein.
Das gilt für DVD-RAM 1x-3x. Bei DVD-RAM 5x werden nur 10000 Schreibvorgänge angegeben. -dnh -- Ich weiß, oh, es kommt auf den Inhalt an. Ich habe aber noch keinen Inhalt gesehen! Keine klare Linie, keine Vision! Was passiert denn eigentlich in der großen Koalition? Gar nix! Eunuchenpolitik! Viel Gefummel, null Penetration! -- Michael Mittermaier, "Paranoid" -- 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
Am Mittwoch, 3. Januar 2007 20:56 schrieb Heiner Kuhlmann:
Am Mittwoch, 3. Januar 2007 10:33 schrieb Volker Kuhlmann:
On Wed 03 Jan 2007 21:18:17 NZDT +1300, Heiner Kuhlmann wrote:
ich kann Probleme mit DVD-RAM mit UDF und einer Fehlermeldung wie bei Steffen bestätigen. Zunächst hatte ich den Fehler auf LG-Laufwerke geschoben, weil der Fehler in der Hitze des Sommers bei mir und bei einem Kunden gleichzeitig auftrat. Ein neues Laufwerk erzeugte vor ein paar Tagen den gleichen Fehler. Die Inspektion aller Medien brachte dann auch Fehler auf Medien, die bereits vor einem Jahr erstellt wurden. Der Fehler taucht vermutlich dann auf, wenn Dateien gelöscht wurden.
Nicht gut.
Der Fehler kann an UDF-Dateisystem selbst oder an der Linux-Implementation liegen.
Was ist denn "UDF Dateisystem selbst"? Wohl eher an der Implementierung...
Konzept des Dateisystems (was passiert beim Rechner-Absturuz?). Ich vermute es liegt an der Implementierung. Im Internet habe ich eine Frage zu diesem Problem gefunden allerdings ohne Antwort.
Der Bericht des ZDF über die Unzuverlässigkeit von CD und DVD hat mich ins Grübeln gebracht. Wie Zuverlässig sind DVD-RAMs tatsächlich?
Wie ich auf einer anderen Liste gelesen habe, sind DVD+-R(W) Konsumerformate, Zuverlässigkeit und Datensicherheit stehen deshalb an Stelle 15. DVDRAM ist schon deutlich älter, und von vornherein auf Archivierung ausgelegt. Da macht wohl der Brenner selbst auch automatisch eine Verfifizierung der geschriebenen Blöcke. Wiederbeschreibbarkeit ist enorm, zB die von DVD+RW ist ja bekanntlich schlecht. Genaueres zu DVDRAM würde mich auch interessieren. Der Rest der Formate ist so wie CD, wobei löschbare Scheiben eine deutlich höhere Ausfallrate als +-R haben.
Ich verwende DVD-RAM, weil sie sehr zuverlässig sein sollen. Sie sollen bis zu 100000 mal beschreibbar sein. Ich schreibe nur tar-Archive drauf in der Größenordnung von 100. Auf einigen DVD-RAMs wurden Dateien gelöscht. Hier traten die Probleme auf. Meine ältesten DVD-RAMs (auf denen nicht gelöscht wurde) sind über ein Jahr alt und ohne Fehler. Wenn Fehler auftraten waren es immer Fehler im Dateisystem selbst in der Art von (unter root)
ls: cannot access /media/MEI_UDF/DVD-RAM_1167184166/home/uml.tgz: Permission denied
Ich habe - bis jetzt - keinen Fehler beim Lesen von Datei-Inhalten gehabt.
Allerdings kam es zu Problemen, weil sich der umount einer DVD-RAM aufhängte.
Ich hatte auch DVD-RAMs, die von dem Brenner nicht mehr angenommen wurden. Meine Vermutung war, dass der Brenner defekt war. Muss ich noch einmal genauer untersuchen.
Ich werde eine DVD-RAM mit ext3 einmal quälen: mit etwa 100 Dateien vollschreiben, testen, löschen usw.
Mein Test: Brenner LG GSA-E10N (externe USB-Version) DVD-RAM von Panasonic 2-3 x Speed Diese DVD-RAM hatte zuvor mit UDF Probleme Filesystem ext3 Leere DVD-RAM: Filesystem 1K-blocks Used Available Use% Mounted on /dev/sr0 4403064 139968 4039428 4% /media/Save Volle DVD-RAM Filesystem 1K-blocks Used Available Use% Mounted on /dev/sr0 4403064 4353516 0 100% /media/Save Schreiben von 43 Dateien mit 4,0GB in ~ 3333s => ~ 1,2MB/s Lesen der 43 Dateien mit 4,0GB in ~ 1700s => ~ 2,4MB/s Die Daten wurden 14 mal geschrieben und gelesen jeweils ohne Fehler. Offensichtlich kein Fehler der Hardware - sprich der DVD-RAM. Ich werde jetzt den Test mit einer neuen DVD-RAM und UDF-System wiederholen. Gruß Heiner -- 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
Hallo, On 03-Jan-2007 Heiner Kuhlmann wrote:
ich kann Probleme mit DVD-RAM mit UDF und einer Fehlermeldung wie bei Steffen bestätigen. Zunächst hatte ich den Fehler auf LG-Laufwerke
Das Problem ist vor einiger Zeit ausfuehrlich in de.comp.hardware.laufwerke.brenner diskutiert worden.
Ich habe inzwischen ein Medium mit ext3 versehen und es mehrfach vollgeschrieben.
Was heisst vollgeschrieben? Wenn du alle Dateien einzeln raufschreibst, duerftest du sehr schnell Probleme bekommen, weil DVD-RAM nur relativ wenige schreibende Zugriffe erlauben. Und ext2 schreibt bei jedem lesenden Zugriff die neue atime auf die Scheibe. Wenn du Pech hast, sind einzelne Bereiche sehr schnell hinueber. Besser ist es, alles zu taren und dann nur die tar-Datei auf die DVD-RAM zu schreiben.
Nebenbemerkung: Der Bericht des ZDF über die Unzuverlässigkeit von CD und DVD hat mich ins Grübeln gebracht. Wie Zuverlässig sind DVD-RAMs tatsächlich? Auf
Ich kenne den Bericht nicht, aber gebrannte DVD und CD sind in der Tat recht fluechtige Medien und fuer Archive nicht geeignet. DVD-RAM sind in der Hinsicht sehr viel sicherer.
jeden Fall werde ich Daten parallel auf externe Festplatten sichern.
Wenn es um ein Archiv geht, mit Sicherheit besser. Geht es um ein Backup, ist die Beschraenkung auf _ein_ Medium, d.h. _eine_ Festplatte oder _eine_ DVD/CD/DVD-RAM nicht mehr als eine Karikatur. Da es wenig sinnvoll ist, von einer Backup-DVD/CD/DVD-RAM irgendwann eine Kopie als neues Backup zu fertigen, da Fehler dann zwar langsamer, aber trotzdem irgendwann auftreten, fahre ich in groesseren Abstaenden ein Backup auf Festplatte sowie alle paar Tage Backups auf DVD-RAM, die sicherheitshalber an einem entfernten Ort aufbewahrt werden. Beste Gruesse, Heinz. -- Reisefuehrer Bulgarien u.a: http://www.erlebnis-bulgarien.de Reiseberichte Osteuropa: http://www.pahlke-online.de Barrierefreies Webdesign: http://www.Pahlke-KunstWebDesign.de -- 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
Hallo Liste,
Grübeln gebracht. Wie Zuverlässig sind DVD-RAMs tatsächlich? Auf
Ich kenne den Bericht nicht, aber gebrannte DVD und CD sind in der Tat recht fluechtige Medien und fuer Archive nicht geeignet.
DVD-RAM sind in der Hinsicht sehr viel sicherer.
Hmm, hatte gerade heute ein großes Problem mit der Sicherheit von DVD-RAMs und kann sie nicht mehr als Backup-Medium empfehlen!! Ich hatte versucht den Inhalt von 2 DVD-RAMs wieder- herzustellen (ca. vor 1 1/2 Jahren gesichert). Die eine konnte ich ohne Probleme restaurieren, die andere wird nicht mal mehr vom Laufwerk erkannt (no Media), obwohl ich damals das Backup mehrmals probegelesen habe (und auch schon mal vor ca. einem halben Jahr, Daten davon gelesen habe! Die Lagerung erfolgte in einem nicht zu heißen, trockenen Raum und die Oberfläche der DVD ist visuell nicht beschädigt!! Das Laufwerk ist ein Nec ND45...! Ich hatte glücklicherweise zusätzlich eine "normale" DVD+R gebrannt, von der ich die Daten lesen konnte! Hat irgendjemand Vorschläge und Erfahrungen mit Langzeitarchivierungen?? Ich hätte etwa 30GB Raw-Files zu archivieren!! Grüße und ein Gutes Neues Jahr! Mike PS: ich kann auch dieses Problem mit der Schreibgeschwindigkeit voll bestätigen, obwohl das für mich kein Problem wäre, wenn die Daten dann über einen längeren Zeitraum haltbar wären! -- 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
Hallo, Am Mittwoch 03 Januar 2007 15:55 schrieb Mike Philipp:
Hallo Liste,
[ ... ]
Hmm, hatte gerade heute ein großes Problem mit der Sicherheit von DVD-RAMs und kann sie nicht mehr als Backup-Medium empfehlen!! Ich hatte versucht den Inhalt von 2 DVD-RAMs wieder- herzustellen (ca. vor 1 1/2 Jahren gesichert). Die eine konnte ich ohne Probleme restaurieren, die andere wird nicht mal mehr vom Laufwerk erkannt (no Media), obwohl ich damals das Backup mehrmals probegelesen habe (und auch schon mal vor ca. einem halben Jahr, Daten davon gelesen habe! Die Lagerung erfolgte in einem nicht zu heißen, trockenen Raum und die Oberfläche der DVD ist visuell nicht beschädigt!! Das Laufwerk ist ein Nec ND45...! Ich hatte glücklicherweise zusätzlich eine "normale" DVD+R gebrannt, von der ich die Daten lesen konnte! Hat irgendjemand Vorschläge und Erfahrungen mit Langzeitarchivierungen?? Ich hätte etwa 30GB Raw-Files zu archivieren!!
für Archive kann ich z.B. Mo-Disk's empfehlen, die haben hier im Einsatz und bisher keine Probleme damit. Die Hersteller geben eine "Datenhaltbarkeit" zwischen 20 und 50 Jahren an - ordentliche Lagerbedingungen vorausgesetzt. 10 Jahre haben hier schon einige auf dem Buckel ... und sie sind bis jetzt noch O.K.. Und die Geschwindigkeit ist ordentlich - Erfahrungsgemäß je nach Laufwerk und Medium bis um die 5 MB/s Die Medien gibt es als RW (=RAM) und WORM (=R) als 3,5" bis 2,3GB und als 5,25" bis 9,1GB. Der Nachteil ist der Preis der Laufwerke von ca. 300 ~ 1000 €. Dennoch würde ich Datenarchive immer mindestens doppelt anlegen und an verschiedenen Orten lagern! Eine 100%-Sicherheit gibt es nun mal nirgends nicht ;) MfG Mirko -- +--[ Mirko Richter (RHCE) ]------------------------+ | Networks & Communicationsystems | | Ernst-Thaelmann-Str. 5, D-06774 Soellichau | | E-MAIL: mrichter@nacmr.de WEB: www.nacmr.de | | Tel. +49/(0)34243/3369-50 \\\\ | | Fax. +49/(0)34243/3369-22/-28 (O O) | +-----------------------------------oOOo-(_)-oOOo--+ -- 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
participants (8)
-
David Haller -
Heiner Kuhlmann -
Heinz W. Pahlke -
Mike Philipp -
Mirko Richter -
Sascha Michel -
Steffen Dettmer -
Volker Kuhlmann