I mount my Seagate FreeAgent Pro external harddrive to my Fedora box via USB. I use it as storage for my backups. Recently, it's been giving me some problems. I attempted to contact Seagate and they recommended I diagnose the problem with Seatools. Of course, there's no Seatools for Linux so I had to connect the drive to my Windows box only to have it pass with flying colors:
S.M.A.R.T check: Test was unavailable. Assuming this is because I'm connecting the drive via USB.
Long drive self-test: Passed
Long generic test: Passed
So, before I contact Seagate again (my drive is under warranty), I wanted to see if anyone might have some suggestions on how to to troubleshoot this. Submitted for your analysis, a breakdown of some seemingly related syslog messages.
First, from my fstab:
/dev/sdb /mnt/extdrive ext3 auto,defaults 1 2
Syslog after mounting:
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
It works fine for hours. Then, I get:
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.
Then a few messages stating "rejecting I/O to offling device" followed by an EXT3-fs error regarding some sort of I/O operation. Examples:
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
I get a trace afterwards that looks like this:
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 ]---
Finally, get a bunch of messages informing me of more I/O rejections:
05:01:11 kernel: sd 2:0:0:0: rejecting I/O to offline device
Many times, the above message appears alone. Other times, it's be coupled with an EXT3-fs error that provides an inode numeber and a block number. Examples:
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
So, I power cycle the drive and run fsck. These are the results:
# 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
Now the drive mounts fine and I could write backups as if nothing ever happened. Then after a few hours, it begins the errors again.
As always, much obliged my fellow SU'ers.
