[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: problems with USB disk



On Fri, Oct 22, 2010 at 03:36:44PM +0000, Camaleón wrote:
> On Fri, 22 Oct 2010 14:07:09 +0200, lee wrote:
> 
> > I´m having trouble copying files for backup purposes to an USB disk with
> > rsync. Copying the files sometimes fails with "Input/output error (5)",
> > and I´m getting messages in the syslog like these:
> 
> (...)
> 
> > [128627.397894] EXT4-fs error (device sdf3):> __ext4_get_inode_loc: unable to read inode block - inode=52298807, block=209191011
> 
> That looks like a filesystem error/corruption. Did you fsck-it?

I´ve had this two or three times before when the disk was connected to
an USB 3.0 controller. (It´s an USB 3.0 capable enclosure.) Last time
when there were copying errors, the disk was connected to the USB 3.0
controller. Umount and sync would just hang indefinitely. When I
tried to rmmod the xhci module, the computer froze :(

Suspecting that there might be a problem with USB 3.0 support or the
controller card, I connected the disk to one of the on-board USB 2.0
ports. I created a new FS on the partition and copied about 650GB to
the USB disk. That seemed to work fine, but next time I connected the
disk and started the backup, write errors came up again.

Every time I tried fsck on the partiton after write errors were
reported, fsck found errors and attemted to fix them, but since it´s a
backup, I aborted fsck, re-created the FS and copied everything over
again.

So yes, the FS is corrupted, for no apparent reason. But then, the
messages in the syslog say that sectors can´t be read, which usually
means that the disk has failed. But I don´t know about USB disks.

It´s "only" a backup, but there is no point in a backup as unreliable
as this ...

> > If this wasn´t an USB disk, I would assume that the disk has failed. But
> > with USB, I´m not so sure: can this be some sort of problem with USB,
> > like a connection problem?
> 
> You are also getting timeouts and I/O error. USB host controller/
> enclosure or cable can be also the cause. Can you test the drive in 
> another USB enclosure or attach it directly to the motherboard port?

Well, after two different USB controllers show the same problems, it
seems more likely that the cable, the enclosure or the disk cause the
problems. I probably can´t remove the disk from the enclosure without
breaking the enclosure, and it´s still under warranty. If I can find
the reciept, I can exchange it, but it´s not possible to give the disk
out of my hands without physically destroying it to make sure that the
data cannot be retrieved.


I´m reluctant to do any further testing with this disk connected to an
USB port because there´s the possibility that the computer freezes
again and data gets lost :(


Now if I would re-create the FS again, I could probably copy
everything over without errors, but next time I´d make a backup, I´d
probably have the same problem again.

I´m not sure what to think about it ... It might indicate that the
disk has actually failed because the failure doesn´t become obvious
when writing to a FS that has just been created but only when there´s
already data on the disk and different parts of it might be accessed.

It might also indicate that everything is fine when connecting the
disk, creating a FS and writing data to it --- until I turn off the
disk. If something remains in the internal cache of the disk that
never gets written even though I´m waiting a while before turning off
the disk, what could I do about that?

Afair I tried hdparm -I on this disk when I got it, but it didn´t
work, probably because the disk is connected via USB. So I can´t use
hdparm to try turning off the internal cache.


If the cable or the enclosure were defective, could I sometimes write
about 650GB without problems and sometimes not? I leave the USB cable
plugged in, so no changes between working/failing there.

Perhaps the best way is to get a new USB 3.0 cable and do some testing
on this disk ...


Reply to: