[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] ext4 extent support

From: Bean
Subject: Re: [PATCH] ext4 extent support
Date: Sun, 6 Jul 2008 12:51:43 +0800

On Sun, Jul 6, 2008 at 2:09 AM, Javier Martín <address@hidden> wrote:
> El sáb, 05-07-2008 a las 19:15 +0200, Felix Zielcke escribió:
>> From: "JavierMartín" <address@hidden>
>> Sent: Saturday, July 05, 2008 3:25 PM
>> To: "The development of GRUB 2" <address@hidden>
>> Subject: Re: [PATCH] ext4 extent support
>> >I think flex_bg support is unimplemented right now (at least I didn't
>> >see it anywhere), but it "worked" because it's not being used? Just a
>> >guess
>> I just checked.
>> Kernel 2.6.26-rc8 has a bit code with flex_bg
>> e2fsprogs 1.41WIP from Debian experimantel has a bit more code with flex
>> (not much with flex_bg more flexbg or just _flex)
>> But I don't know much C so I don't understand the code :)
>> Anyway I think the most important ext4 support are extents, because you can
>> enable them by just remounting to ext4 as long as you don't use noextents
>> mount option
>> flex_bg can only be enabled by mkfs.ext4(dev) not afterwards with tune2fs
>> but it's default enabled in mke2fs.conf for ext4(dev)
>> uninit_bg isn't enabled by default and can be enabled afterwards with
>> tune2fs but resize2fs isn't currently working with it
> I mean unimplemented in GRUB right now. IIrc, flex_bg relaxes some of
> the rules governing the location of the metadata block groups or
> something like that, so that they can be placed in "arbitrary"
> locations.


I found the description of flex_bg:

This feature relaxes check restrictions on where each block groups meta data is
located within the storage media. This allows for the allocation of bitmaps or
inode tables outside the block group boundaries in cases where bad blocks forces
us to look for new blocks which the owning block group can not satisfy. This
will also allow for new meta-data allocation schemes to improve performance and

The reallocation only occurs when bad blocks force us to use another
block group, which is quite rare. So we should silently ignore this


reply via email to

[Prev in Thread] Current Thread [Next in Thread]