[kwlug-disc] Media errors on a USB disk

unsolicited unsolicited at swiz.ca
Wed Oct 20 12:30:02 EDT 2010



Eric Gerlach wrote, On 10/20/2010 10:33 AM:
> On Wed, Oct 20, 2010 at 10:08 AM, Khalid Baheyeldin <kb at 2bits.com> wrote:
>> For the weekly backup, I am now getting this error:
>>
>> [2388063.441067] sd 13:0:0:0: [sdb] Result: hostbyte=DID_OK
>> driverbyte=DRIVER_SENSE,SUGGEST_OK
>> [2388063.441073] sd 13:0:0:0: [sdb] Sense Key : Medium Error [current]
>> [2388063.441077] sd 13:0:0:0: [sdb] Add. Sense: Unrecovered read error
>> [2388063.441080] end_request: I/O error, dev sdb, sector 177045897
>> [2388064.495756] sd 13:0:0:0: [sdb] Result: hostbyte=DID_OK
>> driverbyte=DRIVER_SENSE,SUGGEST_OK
>> [2388064.495762] sd 13:0:0:0: [sdb] Sense Key : Medium Error [current]
>> [2388064.495765] sd 13:0:0:0: [sdb] Add. Sense: Unrecovered read error
>> [2388064.495768] end_request: I/O error, dev sdb, sector 177045897
>>
>> If I replace the disk with an identical brand (but has a different make
>> of disk inside), I get other errors.
>>
>> These two disks have been stable and trouble free for about 2 years,
>> with no issues.
>>
>> My questions are:
>>
>> 1. Short of dd if=/dev/sdb, is there a way to detect blocks?
> 
> SpinRite.  Proprietary, but the best I know of.
> 
>> 2. Do we have a way to add the bad blocks to a list that the operating
>> system
>> should ignore, like we had in the old days?
> 
> No, now drives do this internally.  Drives keep a percentage of their
> sectors as spares, and swap them in when needed.  SpinRite helps the
> drive find those bad blocks, recover the data, and then relocate the
> blocks.

Even when the cache is exhausted, the drive should still mark bad 
blocks as bad. I believe you'll notice this as the reported capacity 
of the drive declines.

>> 3. Could this be a quirk of some sort? How do I know for sure if it is
>> really a media problem or some bug/quirk?

Get it off USB, at least long enough to take USB out of the equation. 
Have you added another USB device recently? The USB channel is not 
dedicated so something else could be mucking up the mix. Make sure 
you're not coming off a USB hub, and make sure nothing is on the 
sibling port. (USB chips spin off connectors in pairs.)

- make sure the disk is externally powered, not through the USB bus - 
in case you're running into USB bus power issues.

eSata comes to mind. Worth buying a controller for even. And MUCH 
faster than USB will ever be. Even a v1 controller goes at 1.5 Gbps 
vs. USB II's 480 Mbps. v2 Is 3 Gps. vX is coming. USB drives 
communicate via the USB subsystem, Sata goes direct. If laptop, 
dedicated PCMCIA eSata card?

Perhaps worth pulling the drive out to another computer entirely, long 
enough to run the drive manufacturer's proprietary testing software.

I wonder if an ethernet connected NAS with whatever the equivalent to 
OpenWRT is, or OpenWRT itself, running busybox?, would give you the 
same testing / diagnostic ability as a non-USB connected external 
drive. I believe the issue is that low level drive commands can't be 
issued through the USB interface. Certainly a 1Gbps/full duplex NAS 
should also leave the USB drive in the dust, in terms of speed. (But 
I've never played with a NAS to know.)

Are RAID controllers any better at this than directly connected 
drives? I would guess not as, in the end, this is the disk itself (we 
presume) reporting issues. Whether reported to the USB bus, the RAID 
controller, or directly, disk issues are disk issues.



More information about the kwlug-disc_kwlug.org mailing list