From: Ric Wheeler <rwheeler@redhat.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: "Theodore Ts'o" <tytso@mit.edu>, linux-ext4@vger.kernel.org
Subject: Re: e2fsprogs 1.42-WIP-0702 released
Date: Mon, 04 Jul 2011 18:52:06 +0100 [thread overview]
Message-ID: <4E11FDC6.7040506@redhat.com> (raw)
In-Reply-To: <D24E441E-2821-4BF5-9A8A-423070A2464E@dilger.ca>
On 07/04/2011 06:49 PM, Andreas Dilger wrote:
> 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
>
Sounds like a very good start - thanks!
One thing that might still needs done is to do some of the power failure testing
at this scale?
Ric
next prev parent reply other threads:[~2011-07-04 17:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-04 0:23 e2fsprogs 1.42-WIP-0702 released Theodore Ts'o
2011-07-04 8:54 ` Ric Wheeler
2011-07-04 17:49 ` Andreas Dilger
2011-07-04 17:52 ` Ric Wheeler [this message]
2011-08-09 13:10 ` Eric Sandeen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E11FDC6.7040506@redhat.com \
--to=rwheeler@redhat.com \
--cc=adilger@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).