It's 1.2.11. I haven't tried to run 1.3.x kernels yet, I would prefer
to stop for a while before going to the bleeding edge again :-).
Unless 1.3.x will be stable for "production" use soon, I would like to
see the fixes back in 1.2.x too (after they are well tested, of course).
> 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.
Thanks. Next time I see a directory which was a file, I will do this.
> 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 :-).
OK, thanks, I will be patient :-).
> > 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.
Maybe some simple checksum if CRC is too slow... Of course the corruption
is not limited to the inode table, but I think it is more likely since inodes
are updated more often (even if files are read, atime is updated). Even on
hardware which works well, there is small probability that one bit will get
flipped. There are good reasons why server machines often have RAM with
error correction...
Anyway, I use Linux since over a year and this is the first time I have
some problem with ext2fs. Thanks for the good work!
Regards,
Marek