[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <53EAB777-5F48-4FCB-8CE2-9F49E29C0DCD@dilger.ca>
Date: Thu, 7 Jun 2012 22:43:43 -0600
From: Andreas Dilger <adilger@...ger.ca>
To: Kees Cook <keescook@...omium.org>
Cc: Ted Ts'o <tytso@....edu>, "Darrick J. Wong" <djwong@...ibm.com>,
Sander Eikelenboom <linux@...elenboom.it>,
Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [dm-devel] EXT4-fs error (device dm-42): ext4_mb_generate_buddy:741: group 1904, 32254 clusters in bitmap, 32258 in gd
On 2012-06-07, at 5:38 PM, Kees Cook wrote:
> On Thu, Jun 7, 2012 at 3:54 PM, Ted Ts'o <tytso@....edu> wrote:
>> On Thu, Jun 07, 2012 at 03:40:40PM -0700, Kees Cook wrote:
>>>
>>> FWIW, I was building the filesystem that triggered this as ext4:
>>>
>>> mkfs.ext4 -T default -m 0 -O ^huge_file,^flex_bg -E
>>> discard,lazy_itable_init /dev/mapper/...
>>
>> Ouy of curiosity, was there a reason you chose those particular file
>> system parameters? It's a surprising set, because if you're starting
>> with a fresh file system, enabling flex_bg produces a more optimal
>> file system layout.
>
> The intent of this was to create a small (64M) initial filesystem as
> fast as possible that could be resized (to 3G) on the fly later. (The
> performance of the filesystem did not need to be optimized, just the
> speed of creation so that the create+mount would happen as fast as
> possible, to unblock things waiting for this filesystem to exist.)
Actually, flex_bg should improve mke2fs times, because the inode and
block bitmaps are allocated contiguously on disk.
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
Powered by blists - more mailing lists