On Sun, 17 Oct 2010, Jonathan Thornburg wrote:
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
