4

I have recently bought an external harddrive to use with my Linux notebook. The harddrive is spec'ed at USB 3.0 while the notebook only supports USB 2.0.

The drive seems to work fine when I plug it in. This is the relevant section from /var/log/messages:

Jun 17 20:36:53 mosquito kernel: usb 1-4: new high-speed USB device number 8 using ehci_hcd
Jun 17 20:36:53 mosquito kernel: scsi8 : usb-storage 1-4:1.0
Jun 17 20:36:53 mosquito mtp-probe: checking bus 1, device 8: "/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-4"
Jun 17 20:36:53 mosquito mtp-probe: bus: 1, device: 8 was not an MTP device
Jun 17 20:36:59 mosquito kernel: scsi 8:0:0:0: Direct-Access     BUFFALO  HD-PNTU3         0001 PQ: 0 ANSI: 6
Jun 17 20:36:59 mosquito kernel: sd 8:0:0:0: Attached scsi generic sg1 type 0
Jun 17 20:36:59 mosquito kernel: sd 8:0:0:0: [sdb] 1953463728 512-byte logical blocks: (1.00 TB/931 GiB)
Jun 17 20:36:59 mosquito kernel: sd 8:0:0:0: [sdb] Write Protect is off
Jun 17 20:36:59 mosquito kernel: sd 8:0:0:0: [sdb] Mode Sense: 1f 00 00 08
Jun 17 20:36:59 mosquito kernel: sd 8:0:0:0: [sdb] No Caching mode page present
Jun 17 20:36:59 mosquito kernel: sd 8:0:0:0: [sdb] Assuming drive cache: write through
Jun 17 20:36:59 mosquito kernel: sd 8:0:0:0: [sdb] No Caching mode page present
Jun 17 20:36:59 mosquito kernel: sd 8:0:0:0: [sdb] Assuming drive cache: write through
Jun 17 20:36:59 mosquito kernel: sdb: sdb1
Jun 17 20:36:59 mosquito kernel: sd 8:0:0:0: [sdb] No Caching mode page present
Jun 17 20:36:59 mosquito kernel: sd 8:0:0:0: [sdb] Assuming drive cache: write through
Jun 17 20:36:59 mosquito kernel: sd 8:0:0:0: [sdb] Attached SCSI disk
Jun 17 20:36:59 mosquito ata_id[7293]: HDIO_GET_IDENTITY failed for '/dev/.tmp-block-8:16'
Jun 17 20:37:16 mosquito ntfs-3g[7305]: Version 2012.1.15 external FUSE 28
Jun 17 20:37:16 mosquito ntfs-3g[7305]: Mounted /dev/sdb1 (Read-Write, label "HD-PNTU3", NTFS 3.1)
Jun 17 20:37:16 mosquito ntfs-3g[7305]: Cmdline options: rw,nosuid,nodev,uhelper=udisks
Jun 17 20:37:16 mosquito ntfs-3g[7305]: Mount options: rw,nosuid,nodev,uhelper=udisks,allow_other,nonempty,relatime,fsname=/dev/sdb1,blkdev,blksize=4096
Jun 17 20:37:16 mosquito ntfs-3g[7305]: Ownership and permissions disabled, configuration type 7

I can copy files to the drive and everything seems to work fine. However, as soon as I unmount the drive, I get the following log output:

Jun 17 20:37:23 mosquito ntfs-3g[7305]: Unmounting /dev/sdb1 (HD-PNTU3)
Jun 17 20:37:23 mosquito ata_id[7324]: HDIO_GET_IDENTITY failed for '/dev/sdb'
Jun 17 20:37:24 mosquito kernel: sd 8:0:0:0: [sdb] Device not ready
Jun 17 20:37:24 mosquito kernel: sd 8:0:0:0: [sdb]  Result: hostbyte=0x00 driverbyte=0x08
Jun 17 20:37:24 mosquito kernel: sd 8:0:0:0: [sdb]  Sense Key : 0x2 [current] 
Jun 17 20:37:24 mosquito kernel: sd 8:0:0:0: [sdb]  ASC=0x3a ASCQ=0x0
Jun 17 20:37:24 mosquito kernel: sd 8:0:0:0: [sdb] CDB: cdb[0]=0x28: 28 00 74 6f 7d 00 00 00 08 00
Jun 17 20:37:24 mosquito kernel: end_request: I/O error, dev sdb, sector 1953463552
Jun 17 20:37:24 mosquito kernel: quiet_error: 200 callbacks suppressed
Jun 17 20:37:24 mosquito kernel: Buffer I/O error on device sdb, logical block 244182944

This is repeated with changing values after the logical block part and sometimes without the Buffer I/O error [...] line.

When I try to mount the drive again, the error is repeated again and mount tells me that it cannot read the superblock. The problem only disappears after I plug the drive out and plug it back in.

What could be causing this? Is this likely a driver or compatibility problem or is the disk faulty? How can I verify this?

2
  • I forgot to mention the actual problem, which is that I cannot remount the drive or access it using fdisk after unmounting. Also, I wonder if the drive is really unmounted cleanly or if data loss may occur due to the errors mentioned in the log. Jun 17, 2012 at 19:15
  • @ekaj: The point of unmounting -- in both Linux and Windows -- is only to make the disk contents invisible to the filesystem layer, not to layers below (SATA and SCSI), and not to cause I/O errors to start appearing. The question does not mention "taking away permissions", which would be irrelevant in any case since ata_id runs as root and has complete access to the device. Jun 17, 2012 at 19:17

1 Answer 1

2

Most of my USB storage devices act like this when I EJECT the drive.

Are you umounting the partition yourself, via cmdline, or are you clicking on 'unmount/eject drive' ?

Simply umounting the partition doesn't cause this, while ejecting the partition prevents me from remounting unless I disconnect and reconnect.

You CAN 'reset' the drive's mountability (!) by using partprobe. It's found in the 'parted' package.

Generally has to be run as root to perform the reset (well, it's like a reset).

sudo partprobe

Will refresh all the devices connected, while

sudo partprobe /dev/sdc

will reset/refresh the partitions on the sdc device.

2
  • Thanks! I was using "eject drive". Running mount / umount explicitly fixes the problem. However, using partprobe does not help once the drive is in a "bad" state. Bonus question: Why do umount and "eject drive" behave so differently? Jun 18, 2012 at 5:42
  • 1
    I'd have to guess it's something to do with how the ioctl handles those commands. Think of the same commands on a tape drive (where they likely originated), or today's cd/dvd drive... umount simply un-attaches it, ready for more use later, while eject pops the tray, ready to be removed entirely. so eject doesn't expect something there until there's new info on an insertion of (tape spindle), cd tray closing, usb insertion... But that's an educated guess.
    – lornix
    Jun 18, 2012 at 18:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .