linux-ext4 - Re: e2fsprogs 1.42-WIP-0702 released

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <D24E441E-2821-4BF5-9A8A-423070A2464E@dilger.ca>
Date:	Mon, 4 Jul 2011 11:49:16 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	Ric Wheeler <rwheeler@...hat.com>
Cc:	"Theodore Ts'o" <tytso@....edu>, linux-ext4@...r.kernel.org
Subject: Re: e2fsprogs 1.42-WIP-0702 released

On 2011-07-04, at 2:54 AM, Ric Wheeler wrote:
> On 07/04/2011 01:23 AM, Theodore Ts'o wrote:
>> I've made the first WIP release of e2fsprogs 1.42.  The primary purpose
>> is for people to test the 64-bit functionality and be confident that we
>> didn't introduce any 32-bit regressions.
>> 
>> ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/e2fsprogs-1.42-WIP-0702.tar.gz
>> 
>> This has been built for Debian unstable, so we can get some initial
>> testing.
> 
> Thanks Ted!
> 
> Do we have a specific idea of who is going to be testing and on what size
> file systems?
> 
> We might want to see about getting this ready for Fedora as well at some point....

Ric,
we have been doing fairly thorough testing at 24TB, because that is
the LUN size when using 3TB drives in RAID-6 8+2 config.  One caveat
is that this is only on the Lustre data servers, so it doesn't exercise
namespace operations and external xattrs very much, since there is no
benefit to large LUNs on the metadata server due to the 4B inode limit.

We have also done some testing up to 128TB, which works fine if the
filesystem passes the initial mount, but has occasional problems at
mount due to kmalloc() failures of large data structs, with oops at
ext4_fill_super() cleanup (http://jira.whamcloud.com/browse/LU-136
and http://jira.whamcloud.com/browse/LU-477).  The oops is completely
unrelated to >16TB LUN support, but is in generic error handling in
ext4_fill_super().  Hopefully now that the developer doing this testing
has finished testing 24TB LUNs, she will be able to work on issues
we've found with 128TB+ LUNs.

In our admittedly unrealistic circumstances, e2fsck run time is very
short, due to flex_bg, uninit_bg, and extents avoiding a lot of seeking
and unnecessary IO.  With "lazy_journal_init" and "lazy_itable_init"
the mke2fs time is also very short.

Cheers, Andreas

--
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