From: Ric Wheeler Subject: Re: e2fsprogs 1.42-WIP-0702 released Date: Mon, 04 Jul 2011 18:52:06 +0100 Message-ID: <4E11FDC6.7040506@redhat.com> References: <4E117FB3.3030403@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Theodore Ts'o" , linux-ext4@vger.kernel.org To: Andreas Dilger Return-path: Received: from mx1.redhat.com ([209.132.183.28]:39962 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757058Ab1GDRwK (ORCPT ); Mon, 4 Jul 2011 13:52:10 -0400 In-Reply-To: Sender: linux-ext4-owner@vger.kernel.org List-ID: 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