On Sun, 17 Oct 2010, Jonathan Thornburg wrote:

quoted text
> Summary
> -------
> My primary laptop ("nitrogen") died, so I moved its disk to a backup
> laptop ("oxygen").  That laptop then died. :(  I have now moved the
> former-nitrogen-disk to an external enclosure so that I can access my
> files via USB from still another laptop ("silver").
>
> When I connect the USB cable to silver I see the usual dmesg lines.
> But the former-nitrogen-disk contents are "wierd":
> * fdisk and disklabel look fine, but
> * if I mount any one of the partitions,
>  * 'df -i' looks fine (shows lots of space & inodes used)
>  * but 'ls -a' and 'echo *' say there are no files present
>
> If I try to fsck any of the partitions, I get the following error
> # fsck -p /dev/rsd1a
> CANNOT READ: BLK 128
> /dev/rsd1a: UNEXPECTED INCONSISTENCY; RUN fsck_ffs MANUALLY.
> # fsck -n /dev/rsd1a
> ** /dev/rsd1a (NO WRITE)
>
> CANNOT READ: BLK 128
> CONTINUE? yes
>
> THE FOLLOWING DISK SECTORS COULD NOT BE READ: 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143,
>
> LOOK FOR ALTERNATE SUPERBLOCKS? no
>
> #
> What's suspicious is that I get this identical message (including the
> exact same sector numbers) for *any* partition.  While I could certainly
> imagine that whatever broke nitrogen and oxygen managed to corrupt the
> disk contents, it seems implausible that it would garble the exact same
> list of sectors on each of several different FFS partitions.
>
> Instead, my symptoms look more like a disk-addressing mixup between
> oxygen/nitrogen and the external enclosure.
>
> Can anyone suggest (in more detail) what's going on here, and/or what
> I can do to fix it (i.e., access the former-nitrogen-disk filesystems
> from another laptop)?  I'd at least like to understand the problem a
> bit before I go blindly poking around with fsck...

Hi Jonathan!

There are some USB <-> ATA bridge chips on the market that do not work 
well (or better to say: they do not work at all). Nonetheless, they are 
frequently used in cheap enclosures and adapters, especially in the very 
cheap ones. JMicron JM20337 is well known for this. In my experience - 
there were no visible problems when this bridge was connected to Toshiba 
drives, but it did not work with IBM/Hitachi and WD drives, both when 
powered through USB or independently. Symptoms were similar to what you 
see. Avoid it at all costs.

It also flooded the disk's SMART tables with a lot of ATA CRC Errors. If 
the bridge in your enclosure can do a known SCSI-to-ATA translation, you 
could try smartmontools from ports to check for such (or other) errors, 
something like
# smartctl -a -d usbjmicron /dev/rsd1c

You can also check readability of the sectors directly with dd(1) or 
install the drive inside the laptop. For basic checks, booted install CD 
could be sufficient, both fsck(8) and dd(1) are there.

Regards,
David