나는 내Seagate FreeAgent ProUSB를 통해 Fedora 상자에 외부 하드 드라이브를 연결합니다. 저는 백업용 저장소로 사용하고 있습니다. 최근에는 나에게 몇 가지 문제가 생겼습니다. Seagate에 연락하려고 했더니 Seagate에서 문제 진단을 권유했습니다.Seatools. 물론, Linux용 Seatools가 없기 때문에 드라이브를 Windows 상자에 연결해야만 성공적으로 통과할 수 있었습니다.
스마트체크: 테스트가 불가능했습니다. USB를 통해 드라이브를 연결하기 때문이라고 가정합니다.
장시간 드라이브 자가 테스트: 합격
긴 일반 테스트: 합격
따라서 Seagate에 다시 연락하기 전에(내 드라이브는 보증 기간이 적용됩니다) 이 문제를 해결하는 방법에 대한 제안이 있는지 알고 싶었습니다. 분석을 위해 제출된 일부 겉보기 관련 syslog 메시지에 대한 분석입니다.
먼저, 내 fstab에서:
/dev/sdb /mnt/extdrive ext3 auto,defaults 1 2
마운트 후 Syslog:
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
몇 시간 동안 잘 작동합니다. 그런 다음 다음을 얻습니다.
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.
그런 다음 "오프링 장치에 대한 I/O 거부"를 나타내는 몇 가지 메시지와 일종의 I/O 작업과 관련된 EXT3-fs 오류가 나타납니다. 예:
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
나중에 다음과 같은 추적을 얻습니다.
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 ]---
마지막으로 추가 I/O 거부를 알려주는 여러 메시지를 받습니다.
05:01:11 kernel: sd 2:0:0:0: rejecting I/O to offline device
위의 메시지만 나타나는 경우가 많습니다. 다른 경우에는 inode 번호와 블록 번호를 제공하는 EXT3-fs 오류와 결합됩니다. 예:
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
그래서 드라이브의 전원을 껐다 켜고 fsck를 실행합니다. 결과는 다음과 같습니다.
# 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
이제 드라이브가 제대로 마운트되고 아무 일도 없었던 것처럼 백업을 작성할 수 있습니다. 그런 다음 몇 시간 후에 오류가 다시 시작됩니다.
언제나 그렇듯, 동료 SU'ers에게 큰 은혜를 입혔습니다.
답변1
SATA/USB 브리지에 문제가 있을 수 있습니다. 이를 확인하기 위해 eSata 또는 FireWire를 사용하여 HDD를 연결하려고 합니다.
답변2
운전이 잠자기 상태가 된 것 같습니다. hdparm드라이브의 전원 관리 설정을 제어하는 데 사용할 수 있습니다 .
답변3
드라이브가 이와 같이 작동하는 것을 본 적이 있습니다. 유사한 성격의 오류, 매우 느린 액세스, 그러나 SMART 오류는 없습니다. 몇 주 후에 SMART 오류가 나타나기 시작했습니다. 브리지가 아닌 경우 드라이브가 찌르는 것입니다.