Я монтую зовнішній жорсткий диск Seagate FreeAgent Pro до своєї коробки Fedora через USB. Я використовую його як сховище для своїх резервних копій. Останнім часом це доставляє мені певні проблеми. Я спробував зв’язатися з Seagate, і вони рекомендували мені діагностувати проблему з Seatools . Звичайно, Seatools для Linux немає, тому мені довелося підключити накопичувач до вікна Windows тільки для того, щоб він міг пропускати літаючі кольори:
Перевірка SMART : Тест недоступний. Якщо припустити, це тому, що я підключаю диск через USB.
Самотест на довгій їзді : пройшов
Довгий загальний тест : Пройдено
Отже, перш ніж я знову звертаюся до Seagate (мій диск знаходиться під гарантією), я хотів дізнатись, чи є у когось якісь пропозиції щодо усунення несправностей. На ваш аналіз представлено розрив деяких, здавалося б, суміжних системних журналів.
По-перше, з мого 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.
Потім кілька повідомлень про те, що "відхилення вводу / виводу до пристрою відключення", а потім помилка 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 ]---
Нарешті, отримайте купу повідомлень, що інформують мене про більше відхилень вводу / виводу:
05:01:11 kernel: sd 2:0:0:0: rejecting I/O to offline device
Багато разів вищезгадане повідомлення з’являється поодинці. В інших випадках це поєднується з помилкою 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.