[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGXu5j+mF1jnMXDT-Vpb6T5s34XgTRTeDOdyoXYy_RwNfaUn6w@mail.gmail.com>
Date: Thu, 7 Jun 2012 16:38:31 -0700
From: Kees Cook <keescook@...omium.org>
To: "Ted Ts'o" <tytso@....edu>, Kees Cook <keescook@...omium.org>,
djwong@...ibm.com, Sander Eikelenboom <linux@...elenboom.it>,
Linus Torvalds <torvalds@...ux-foundation.org>,
dm-devel@...hat.com, linux-ext4@...r.kernel.org,
linux-kernel@...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 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.)
In the more common situation, it was built also with:
-b 4096 ... -E ...,resize=MMM ... [device] NNN
where MMM > NNN. And an online resize would be started a bit after it
was created, growing it up to MMM.
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists