linux-ext4 - Re: e2fsprogs-interim scm tree?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <m2ve7vbuvh.fsf@vador.mandriva.com>
Date:	Wed, 21 Nov 2007 14:17:38 +0100
From:	Thierry Vignaud <tvignaud@...driva.com>
To:	Theodore Tso <tytso@....edu>
Cc:	Christian Kujau <lists@...dbynature.de>, linux-ext4@...r.kernel.org
Subject: Re: e2fsprogs-interim scm tree?

Theodore Tso <tytso@....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?
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html