Notes for debugging file systems

Whilst debugging file system corruption with eqe, I was reminded that hexdump is slightly misleading on a perfectly valid directory:

val@nifty:~$ sudo dd skip=1536 count=1 bs=4096 if=/dev/hda5 | hd | less
00000000  02 00 00 00 0c 00 01 02  2e 00 00 00 02 00 00 00  |................|
00000010  0c 00 02 02 2e 2e 00 00  0b 00 00 00 14 00 0a 02  |................|

After all, “.” and “..” look like, well, dots.

(The file system corruption seemed pretty clearly to be the result of a 16GB CF card occasionally ending up with 4K blocks of all zeroes when they ought to be something else. Don’t store data you care about on these things.)

7 thoughts on “Notes for debugging file systems”

  1. Re: where to get that “hd”?

    Maybe you have hexdump? On Debian/Ubuntu, hd is a symlink to hexdump. It’s from the bsdmainutils package.

  2. Re: where to get that “hd”?

    I couldn’t live without a hex dump, and od just isn’t up to the task, so I wrote my own. I’d never thought about it before, but this is a perfect example of the need to have hd take an argument to change the character used for non-printable bytes…

  3. Weird. 16GB cards seem to have random zero problems. This came across the
    OLPC stuff:
    ADATA 16GB SDHC gets corrupted partition block

    I tried an ADATA “Class 6 Turbo” 16GB SDHC.

    I didn’t catch a dmesg message (if any) while the corruption was happening, but multiple times the first sector (partition) was overwritten with zero’s. Restoring said sector seemed to work, but other data may well be corrupted, too. Also, the card appears with a different number after suspend. It looks like the driver and the card disagree about some timings, especially during power up/down. I’d say the driver is wrong by definition, although the card may very well be wrong, too.

    In any case, the combination of XO + this card isn’t usable, whereas same card seems very usable when used by other computers.

    Makes me wonder if there is a common problem.

Comments are closed.