[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
mailing list