Re: e2fsprogs-interim scm tree?

[Thierry Vignaud <tvignaud@mandriva.com>]

Theodore Tso <tytso@mit.edu> writes:

> Oh, absolutely.  I just don't think it's fair to encourage people to
> use something that might cause them to risk their data unless they
> are going into it with their eyes wide open.  The 'pu' branch gets
> very minimal testing.  I do run the regression test suite(*), so
> it's a bit more than "it builds, ship it!", but essentially almost
> any patch that will apply gets thrown into 'pu', and as I review
> patches and fix up issues, I move them to the 'next' branch, and
> then a little bit later to the 'master' branch.
> 
> (*) With only 3-4 test failures, but at least some of them are tests
> that need to be fixed up, not necessarily outright bugs in the 'pu'
> branch.
> 
> At the moment in the git tree only the 'pu' branch has extents
> support, and to be honest the support in e2fsprogs-interim in terms of
> being able to better detect and fix corrupted filesystems without
> crashing.  (Some of the newer features like uninit groups and flexbg
> isn't in e2fsprogs-interim, though.)  Fixing up the extents support is
> very high on my priority list over the next couple of weeks, but at
> the moment e2fsck on the 'pu' branch will correctly check an ext4
> filesystem with extents that isn't too badly corrupted; a badly
> corrupted one will cause e2fsck to crash.  It will get better, I
> promise you!  :-)

With the pu branch (98ec405d684b41be4ed8c3911dc7796bbacb8c68), I saw
lot of:

Error while reading over extent tree in inode 395164: Corrupt extent header    
Clear inode<y>? yes

Error while reading over extent tree in inode 395165: Corrupt extent header
Clear inode<y>? yes

Error while reading over extent tree in inode 395166: Corrupt extent header
Clear inode<y>? yes

Error while reading over extent tree in inode 395167: Corrupt extent header
Clear inode<y>? yes

Error while reading over extent tree in inode 410957: Corrupt extent header    
Clear inode<y>? yes

 


It's on a ext4 formated a week ago that sees lots of rsync tests.
And indeed, ls reporst some strange inodes:

(...)
-rw-r--r-- 1 tv    64876 2007-11-12 11:37 lang.pm
l????????? ? ?         ?                ? list_modules.pm
(...)

Would it be a kernel issue then?