All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.