Can you please tell me the version of the kernel that you are
using? Recent versions of the kernel (i.e. Linux 1.3.9) should print
a more precise error message than just ``bad directory''.
> I really hope to see a new e2fsck able to fix this soon - I don't know
> enough about filesystem structure to fix it by hand. Thanks and please
> keep up the good work.
If you know the inode number of the bad directory, you can
removed it by using debugfs. Under debugfs, type ``clri <inode-number>''
and the whole inode will be zeroed. After this, unmount the filesystem,
run e2fsck on it (it should complain about blocks unallocated but marked
as allocated, this is normal), and it should fix the problem.
I think that the next version of the e2fsprogs will contain a
fixed e2fsck (I know how to fix this problem, I just need to find some
free time and I have planned to party next week-end :-).
> Just an idea: how about CRC checksums for inodes? This would allow easy
> detection of such problems, and the hardware Linux is running on is not
> always the highest quality... I can only dream about RAM with ECC, the
> motherboard in this box doesn't even seem to support parity. Single bit
> in an inode can make a big difference, and inodes are updated very often
> compared to files.
Well, this may be a bad thing for performance. Every time the kernel
reads an inode, it should verify the checksum and the checksum should be
recomputed every time a field is changed in the inode. I am afraid that
this would slow down things a lot. Anyway, if your hardware causes data
corruption, there is no reason that this corruption is limited to the inode
table, it can be anywhere in the data blocks, and you can loose your data too.
>
> Regards,
> Marek
>
Remy