Rsync + große Platten: Probleme bekannt? Oder mit Firewire unter 9.2 ?
Hallo, ich habe hier eine neue 250 GB Platte, extern mit Firewire an meinen Linux-PC angeschlossen. Nach dem einrichten und formatieren habe ich mit rsync Daten raufkopieren wollen. Dabei ist irgendwas unnormal verlaufen. Irgendwann kamen nur Fehler im message log und die Platte war nicht mehr ansprechbar (rsync hatte sich gekillt). Könnte es sein, daß es für rsync zu groß ist? Ich vermute auch Probleme mit Firewire und der SuSE 9.2 Version, weil wir mit einem SLES 9 Rechner große Probleme haben, externe Platten stabil anzusprechen. Linux oexs8 2.6.8-24.20-default #1 Thu Feb 2 20:46:50 UTC 2006 i686 athlon i386 GNU/Linux rsync version 2.6.3pre1 protocol version 28 fdisk /dev/sdb Disk /dev/sdb: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdb1 1 30401 244196001 83 Linux mkfs.ext3 -L "Backup2Disk" /dev/sdb1 Aus dem message log nach einem rsync Kommando: Apr 9 18:22:36 oexs8 kernel: ieee1394: Node resumed: ID:BUS[0-00:1023] GUID[0050770e40006b90] Apr 9 18:22:36 oexs8 kernel: ieee1394: Node changed: 0-00:1023 -> 0-01:1023 Apr 9 18:22:36 oexs8 kernel: ieee1394: unsolicited response packet received - no tlabel match Apr 9 18:22:36 oexs8 kernel: scsi3 : SCSI emulation for IEEE-1394 SBP-2 Devices Apr 9 18:22:37 oexs8 kernel: ieee1394: sbp2: Logged into SBP-2 device Apr 9 18:22:37 oexs8 kernel: ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048] Apr 9 18:22:37 oexs8 kernel: Vendor: SAMSUNG Model: SP2514N Rev: Apr 9 18:22:37 oexs8 kernel: Type: Direct-Access ANSI SCSI revision: 06 Apr 9 18:22:37 oexs8 kernel: SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB) Apr 9 18:22:37 oexs8 kernel: SCSI device sdb: drive cache: write through Apr 9 18:22:37 oexs8 kernel: SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB) Apr 9 18:22:37 oexs8 kernel: SCSI device sdb: drive cache: write through Apr 9 18:22:37 oexs8 kernel: sdb: sdb1 Apr 9 18:22:37 oexs8 kernel: Attached scsi disk sdb at scsi3, channel 0, id 0, lun 0 Apr 9 18:22:37 oexs8 kernel: Attached scsi generic sg1 at scsi3, channel 0, id 0, lun 0, type 0 Apr 9 18:22:46 oexs8 /etc/dev.d/block/50-hwscan.dev[30346]: new block device /block/sdb Apr 9 18:22:46 oexs8 /etc/dev.d/block/51-subfs.dev[30360]: mount block device /block/sdb Apr 9 18:22:46 oexs8 /etc/dev.d/block/50-hwscan.dev[30350]: new block device /block/sdb/sdb1 Apr 9 18:22:46 oexs8 /etc/dev.d/block/51-subfs.dev[30386]: mount block device /block/sdb/sdb1 Apr 9 18:22:49 oexs8 /etc/dev.d/block/51-subfs.dev[30386]: mount disk/by-path/ieee1394-0050770e40006b90-0-0p1 Apr 9 18:23:38 oexs8 root: Starting rsync backup from oexs8... Apr 9 18:23:39 oexs8 kernel: JBD: barrier-based sync failed on sdb1 - disabling barriers Apr 9 18:38:16 oexs8 kernel: ieee1394: sbp2: aborting sbp2 command Apr 9 18:38:16 oexs8 kernel: Write (10) 00 15 0c 8b 77 00 00 f8 00 Apr 9 18:38:46 oexs8 kernel: ieee1394: sbp2: aborting sbp2 command Apr 9 18:38:46 oexs8 kernel: Test Unit Ready 00 00 00 00 00 Apr 9 18:38:46 oexs8 kernel: ieee1394: sbp2: aborting sbp2 command Apr 9 18:38:46 oexs8 kernel: Write (10) 00 15 0c 8c 6f 00 00 f8 00 Apr 9 18:39:16 oexs8 kernel: ieee1394: sbp2: aborting sbp2 command Apr 9 18:39:16 oexs8 kernel: Test Unit Ready 00 00 00 00 00 Apr 9 18:39:16 oexs8 kernel: ieee1394: sbp2: aborting sbp2 command Apr 9 18:39:16 oexs8 kernel: Write (10) 00 15 0c 8d 67 00 00 f8 00 Apr 9 18:39:46 oexs8 kernel: ieee1394: sbp2: aborting sbp2 command Apr 9 18:39:46 oexs8 kernel: Test Unit Ready 00 00 00 00 00 Apr 9 18:39:46 oexs8 kernel: ieee1394: sbp2: aborting sbp2 command Apr 9 18:39:46 oexs8 kernel: Write (10) 00 15 0c 8e 5f 00 00 f8 00 Apr 9 18:40:16 oexs8 kernel: ieee1394: sbp2: aborting sbp2 command Apr 9 18:40:16 oexs8 kernel: Test Unit Ready 00 00 00 00 00 Apr 9 18:40:16 oexs8 kernel: ieee1394: sbp2: aborting sbp2 command Apr 9 18:40:16 oexs8 kernel: Write (10) 00 15 0c 8f 57 00 00 f8 00 Apr 9 19:31:21 oexs8 kernel: scsi3 (0:0): rejecting I/O to offline device Apr 9 19:31:21 oexs8 kernel: EXT3-fs error (device sdb1): ext3_find_entry: reading directory #22052950 offset 0 Apr 9 19:31:21 oexs8 kernel: Apr 9 19:35:18 oexs8 kernel: scsi3 (0:0): rejecting I/O to offline device Apr 9 19:35:18 oexs8 kernel: EXT3-fs error (device sdb1): ext3_find_entry: reading directory #22052950 offset 0 Apr 9 19:35:18 oexs8 kernel: Apr 9 19:35:19 oexs8 kernel: scsi3 (0:0): rejecting I/O to offline device Apr 9 19:35:19 oexs8 kernel: EXT3-fs error (device sdb1): ext3_find_entry: reading directory #22052950 offset 0 Apr 9 19:35:19 oexs8 kernel: Apr 9 19:35:19 oexs8 kernel: scsi3 (0:0): rejecting I/O to offline device Apr 9 19:35:19 oexs8 kernel: EXT3-fs error (device sdb1): ext3_find_entry: reading directory #22052950 offset 0 Apr 9 19:35:19 oexs8 kernel: Apr 9 19:35:30 oexs8 kernel: scsi3 (0:0): rejecting I/O to offline device Apr 9 19:35:30 oexs8 kernel: EXT3-fs error (device sdb1): ext3_find_entry: reading directory #22052950 offset 0 Apr 9 19:35:30 oexs8 kernel: Apr 9 19:35:39 oexs8 root: Fatal: rsync finished oexs8 with errors! Apr 9 19:35:39 oexs8 root: Finished rsync backup from oexs8... Apr 9 19:35:40 oexs8 kernel: scsi3 (0:0): rejecting I/O to offline device Apr 9 19:35:40 oexs8 kernel: EXT3-fs error (device sdb1): ext3_find_entry: reading directory #2 offset 0 Apr 9 19:35:40 oexs8 kernel: Apr 9 19:35:40 oexs8 root: Starting rsync backup from ws24... pr 9 19:42:59 oexs8 root: Fatal: rsync finished ws24 with errors! Apr 9 19:42:59 oexs8 root: Finished rsync backup from ws24... Apr 9 19:42:59 oexs8 kernel: __journal_remove_journal_head: freeing b_frozen_data Apr 9 19:42:59 oexs8 last message repeated 3 times Apr 9 19:42:59 oexs8 kernel: __journal_remove_journal_head: freeing b_committed_data Apr 9 19:42:59 oexs8 kernel: scsi3 (0:0): rejecting I/O to offline device Apr 9 19:42:59 oexs8 kernel: printk: 25 messages suppressed. Apr 9 19:42:59 oexs8 kernel: Buffer I/O error on device sdb1, logical block 535 Apr 9 19:42:59 oexs8 kernel: lost page write due to I/O error on sdb1 Apr 9 19:43:20 oexs8 submountd: unable to determine filesystem type Apr 9 19:43:20 oexs8 submountd: mount failure, Success Apr 9 19:43:20 oexs8 kernel: subfs: unsuccessful attempt to mount media (256)
Manfred Rebentisch, Montag, 10. April 2006 09:44:
Könnte es sein, daß es für rsync zu groß ist? Ich vermute auch Probleme mit Firewire und der SuSE 9.2 Version, weil wir mit einem SLES 9 Rechner große Probleme haben, externe Platten stabil anzusprechen.
Also für rsync ist das kein Problem, ich mache das mit noch deutlich größeren Datenmengen, und hatte noch kein Problem in dieser Art. Ich nehme zwar immer xfs statt ext2/3, aber ich denke nicht, daß das einen Unterschied macht. Mir scheint es eher an der Einbindung der Platte an sich zu liegen.
Apr 9 18:23:38 oexs8 root: Starting rsync backup from oexs8... Apr 9 18:23:39 oexs8 kernel: JBD: barrier-based sync failed on sdb1 - disabling barriers [...] Apr 9 19:31:21 oexs8 kernel: scsi3 (0:0): rejecting I/O to offline device Apr 9 19:31:21 oexs8 kernel: EXT3-fs error (device sdb1): ext3_find_entry: reading directory #22052950 offset 0 [...] Apr 9 19:42:59 oexs8 kernel: lost page write due to I/O error on sdb1 Apr 9 19:43:20 oexs8 submountd: unable to determine filesystem type Apr 9 19:43:20 oexs8 submountd: mount failure, Success Apr 9 19:43:20 oexs8 kernel: subfs: unsuccessful attempt to mount media (256)
Irgendwie hat der Kernel ein Problem, sich mit der Platte vernünftig zu unterhalten. Wie wäre es, wenn Du mal den automount/subfs-Krams abschaltest, und ganz normal und altmodisch mountest? -- Andre Tann
Hallo Andre, Am Montag, 10. April 2006 10:08 schrieb Andre Tann:
Irgendwie hat der Kernel ein Problem, sich mit der Platte vernünftig zu unterhalten. Wie wäre es, wenn Du mal den automount/subfs-Krams abschaltest, und ganz normal und altmodisch mountest?
Zwar hat mein Script selbst gemountet, aber Du hast auch recht: das System hat im Hintergrund ebenfalls gemountet. Das muß ich mal abstellen (puh!) und dann teste ich nochmal. Danke, Manfred
Hallo, Am Mon, 10 Apr 2006, Manfred Rebentisch schrieb:
Am Montag, 10. April 2006 10:08 schrieb Andre Tann: [..] Zwar hat mein Script selbst gemountet, aber Du hast auch recht: das System hat im Hintergrund ebenfalls gemountet.
*aua* Ansonsten wuerde ich mal in 2 Partitionen kleiner als 127 GB erstellen (also z.B. eine mit 15200 Zylindern und eine mit dem Rest). -dnh --
Good. now let's bash PHP. -- Satya I thought we were talking about programming languages? -- Peter Corlett
Hallo Andre, Am Montag, 10. April 2006 10:08 schrieb Andre Tann:
Irgendwie hat der Kernel ein Problem, sich mit der Platte vernünftig zu unterhalten. Wie wäre es, wenn Du mal den automount/subfs-Krams abschaltest, und ganz normal und altmodisch mountest?
nun hatte ich mal ohne hotplug-dämon getestet, aber mit dem gleichen Ergebnis. Jetzt teste ich nochmal mit einer anderen Platte, aber ich glaube, daß das ein Systemfehler ist und nicht ein Festplattenfehler. Manfred
Manfred Rebentisch wrote:
ich habe hier eine neue 250 GB Platte, extern mit Firewire an meinen Linux-PC angeschlossen. Nach dem einrichten und formatieren habe ich mit rsync Daten raufkopieren wollen. Dabei ist irgendwas unnormal verlaufen. Irgendwann kamen nur Fehler im message log und die Platte war nicht mehr ansprechbar (rsync hatte sich gekillt). Könnte es sein, daß es für rsync zu groß ist?
Ich habe keine Erfahrung mit FireWire, aber eine 300GB grosse externe USB2 Festplatte angeschlossen, die ich ebenfalls via rsync als Backup Medium fuer meinen Laptop benutze. Fuer rsync ist das alles kein Problem. Ich schaetze daher, dass Dein Problem eher woanders zu suchen ist.
Ich vermute auch Probleme mit Firewire und der SuSE 9.2 Version, weil wir mit einem SLES 9 Rechner große Probleme haben, externe Platten stabil anzusprechen. [...] Apr 9 19:43:20 oexs8 kernel: subfs: unsuccessful attempt to mount media (256)
Als erstes wuerde ich mal subfs abschalten. Wenn das Medium ueber subfs gemountet wird, duerfte auch die "sync" Option im Spiel sein und sorgt vermutlich fuer schlechte Performance. Ich brauche fuer ein Backup mehr als 10 mal so lange ueber USB2, wenn die "sync" Option statt der "async" Option verwendet wird beim Mounten. Ohne submount musst Du natuerlich die Platte dann erst einmal von Hand einbinden - evtl. behebt das aber schon Deine Probleme, also einfach mal schauen. Ansonsten wuerde ich auch mal das Kernel-Log checken, ob es bzgl. FireWire groessere Updates bei neueren Kerneln gegeben hat. Unter Umstaenden wuerde sich dann ein Upgrade des Kernels lohnen. Cheers, Th.
participants (4)
-
Andre Tann -
David Haller -
Manfred Rebentisch -
Thomas Hertweck