Ich besteige meineSeagate FreeAgent Proexterne Festplatte über USB an meine Fedora-Box anschließen. Ich verwende sie als Speicher für meine Backups. In letzter Zeit habe ich einige Probleme damit. Ich habe versucht, Seagate zu kontaktieren und sie haben mir empfohlen, das Problem mitSeewerkzeuge. Natürlich gibt es keine Seatools für Linux, also musste ich das Laufwerk an meine Windows-Box anschließen, was aber mit Bravour geklappt hat:
SMART-Check: Test war nicht verfügbar. Ich nehme an, das liegt daran, dass ich das Laufwerk über USB anschließe.
Langer Laufwerk-Selbsttest: Bestanden
Langer generischer Test: Bestanden
Bevor ich mich also erneut an Seagate wende (mein Laufwerk ist noch durch die Garantie abgedeckt), wollte ich fragen, ob jemand Vorschläge zur Fehlerbehebung hat. Zu Ihrer Analyse habe ich eine Aufschlüsselung einiger scheinbar zusammenhängender Syslog-Meldungen eingereicht.
Zunächst aus meiner fstab:
/dev/sdb /mnt/extdrive ext3 auto,defaults 1 2
Syslog nach dem Mounten:
19:47:25 kernel: usb 1-1: new high speed USB device using ehci_hcd and address 5
19:47:25 kernel: usb 1-1: New USB device found, idVendor=0bc2, idProduct=3022
19:47:25 kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=9
19:47:25 kernel: usb 1-1: Product: FreeAgent Pro
19:47:25 kernel: usb 1-1: Manufacturer: Seagate
19:47:25 kernel: usb 1-1: SerialNumber: OBFUSCATED
19:47:25 kernel: scsi3 : usb-storage 1-1:1.0
19:47:26 kernel: scsi 2:0:0:0: Direct-Access Seagate FreeAgent Pro 400A PQ: 0 ANSI: 4
19:47:26 kernel: sd 2:0:0:0: Attached scsi generic sg1 type 0
19:47:26 kernel: sd 2:0:0:0: [sdb] 625142448 512-byte logical blocks: (320 GB/298 GiB)
19:47:26 kernel: sd 2:0:0:0: [sdb] Write Protect is off
19:47:26 kernel: sd 2:0:0:0: [sdb] Assuming drive cache: write through
19:47:26 kernel: sd 2:0:0:0: [sdb] Assuming drive cache: write through
19:47:26 kernel: sdb: sdb1
19:47:26 kernel: sd 2:0:0:0: [sdb] Assuming drive cache: write through
19:47:26 kernel: sd 2:0:0:0: [sdb] Attached SCSI disk
19:47:26 kernel: EXT3-fs (sdb): using internal journal
19:47:26 kernel: EXT3-fs (sdb): mounted filesystem with ordered data mode
Es funktioniert stundenlang einwandfrei. Dann bekomme ich:
05:01:10 kernel: usb 1-1: reset high speed USB device using ehci_hcd and address 2
05:01:11 kernel: sd 2:0:0:0: Device offlined - not ready after error recovery
05:01:11 kernel: sd 2:0:0:0: [sdb] Unhandled sense code
05:01:11 kernel: sd 2:0:0:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
05:01:11 kernel: sd 2:0:0:0: [sdb] Sense Key : Hardware Error [current]
05:01:11 kernel: sd 2:0:0:0: [sdb] Add. Sense: No additional sense information
05:01:11 kernel: sd 2:0:0:0: [sdb] CDB: Read(10): 2a bc 19 7b d5 10 00 00 08 88
05:01:11 kernel: end_request: I/O error, dev sdb, sector 393991440
05:01:11 kernel: sd 2:0:0:0: rejecting I/O to offline device
05:01:11 kernel: Aborting journal on device sdb.
Dann ein paar Meldungen mit dem Hinweis „E/A zum Offling-Gerät wird abgelehnt“, gefolgt von einem EXT3-fs-Fehler bezüglich einer Art E/A-Operation. Beispiele:
05:01:11 kernel: sd 2:0:0:0: rejecting I/O to offline device
05:01:11 kernel: EXT3-fs (sdb): error in ext3_reserve_inode_write: Journal has aborted
05:01:11 kernel: sd 2:0:0:0: rejecting I/O to offline device
05:01:11 kernel: EXT3-fs (sdb): error in ext3_dirty_inode: Journal has aborted
05:01:11 kernel: sd 2:0:0:0: rejecting I/O to offline device
05:01:11 kernel: EXT3-fs error (device sdb): empty_dir: error -5 reading directory #24609027 offset 0
Ich erhalte anschließend eine Ablaufverfolgung, die folgendermaßen aussieht:
05:01:11 kernel: ------------[ cut here ]------------
05:01:11 kernel: WARNING: at fs/buffer.c:1159 mark_buffer_dirty+0x28/0x7e()
05:01:11 kernel: Hardware name: CM-iAM/SBC-FITPC2i
05:01:11 kernel: Modules linked in: coretemp sunrpc cpufreq_ondemand acpi_cpufreq ipv6 xt_multiport iptable_mangle ipt_MASQUERADE ipt_LOG xt_recent iptable_nat nf_nat pegasus i2c_isch sch_gpio i2c_core microcode lpc_sch serio_raw mfd_core r8169 mii ata_generic pata_acpi usb_storage pata_sch video output [last unloaded: scsi_wait_scan]
05:01:11 kernel: Pid: 22721, comm: rm Not tainted 2.6.34.7-56.fc13.i686.PAE #1
05:01:11 kernel: Call Trace:
05:01:11 kernel: [<c043f32a>] warn_slowpath_common+0x6a/0x81
05:01:11 kernel: [<c04f5f50>] ? mark_buffer_dirty+0x28/0x7e
05:01:11 kernel: [<c043f353>] warn_slowpath_null+0x12/0x15
05:01:11 kernel: [<c04f5f50>] mark_buffer_dirty+0x28/0x7e
05:01:11 kernel: [<c052a6d8>] ext3_commit_super.clone.0+0x47/0x53
05:01:11 kernel: [<c052a75d>] ext3_handle_error+0x79/0x9d
05:01:11 kernel: [<c052a7dc>] __ext3_std_error+0x5b/0x76
05:01:11 kernel: [<c052a82d>] __ext3_journal_stop+0x36/0x3d
05:01:11 kernel: [<c0523c20>] ext3_dirty_inode+0x64/0x6c
05:01:11 kernel: [<c04f1076>] __mark_inode_dirty+0x28/0xf8
05:01:11 kernel: [<c04e9690>] touch_atime+0xcb/0xeb
05:01:11 kernel: [<c04e5a1e>] vfs_readdir+0x7b/0x94
05:01:11 kernel: [<c04e572c>] ? filldir64+0x0/0xd0
05:01:11 kernel: [<c04e5a9f>] sys_getdents64+0x68/0xaa
05:01:11 kernel: [<c0408c9f>] sysenter_do_call+0x12/0x28
05:01:11 kernel: ---[ end trace 7d73d2e1814cadc7 ]---
Schließlich erhalte ich eine Reihe von Nachrichten, die mich über weitere E/A-Ablehnungen informieren:
05:01:11 kernel: sd 2:0:0:0: rejecting I/O to offline device
Häufig wird die obige Meldung allein angezeigt. Manchmal ist sie mit einem EXT3-fs-Fehler verbunden, der eine Inode-Nummer und eine Blocknummer angibt. Beispiele:
05:01:11 kernel: sd 2:0:0:0: rejecting I/O to offline device
05:01:11 kernel: EXT3-fs error (device sdb): ext3_get_inode_loc: unable to read inode block - inode=24904304, block=49807381
05:01:11 kernel: sd 2:0:0:0: rejecting I/O to offline device
05:01:11 kernel: EXT3-fs error (device sdb): ext3_get_inode_loc: unable to read inode block - inode=24904304, block=49807381
05:01:11 kernel: sd 2:0:0:0: rejecting I/O to offline device
05:01:11 kernel: EXT3-fs error (device sdb): ext3_get_inode_loc: unable to read inode block - inode=24986702, block=49971236
05:01:11 kernel: sd 2:0:0:0: rejecting I/O to offline device
05:01:11 kernel: EXT3-fs error (device sdb): ext3_get_inode_loc: unable to read inode block - inode=24986702, block=49971236
Also schalte ich das Laufwerk aus und wieder ein und führe fsck aus. Dies sind die Ergebnisse:
# fsck -f -y /dev/sdb
fsck from util-linux-ng 2.17.2
e2fsck 1.41.10 (10-Feb-2009)
/extdrive: recovering journal
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/extdrive: ***** FILE SYSTEM WAS MODIFIED *****
/extdrive: 632570/39075840 files (1.6% non-contiguous), 59419817/78142806 blocks
Jetzt wird das Laufwerk problemlos gemountet und ich konnte Backups schreiben, als wäre nie etwas passiert. Dann, nach ein paar Stunden, beginnen die Fehler wieder.
Wie immer bin ich meinen SU-Kollegen sehr verbunden.
Antwort1
Möglicherweise liegt ein Problem mit der SATA/USB-Brücke vor. Um das zu überprüfen, würde ich versuchen, die Festplatte mit eSata oder FireWire anzuschließen.
Antwort2
Ihr Laufwerk ist wahrscheinlich in den Ruhezustand gewechselt. Sie können hdparmdie Energieverwaltungseinstellungen des Laufwerks steuern.
Antwort3
Ich habe Laufwerke gesehen, die sich ähnlich verhalten – Fehler ähnlicher Art, sehr langsame Zugriffe, aber keine SMART-Fehler. Ein paar Wochen später tauchten die SMART-Fehler auf. Wenn es nicht die Brücke ist, ist Ihr Laufwerk angeschlagen.