All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Felipe Monteiro de Carvalho <felipemonteiro.carvalho@gmail.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Beginner questions about ext4
Date: Sun, 23 Jun 2013 07:59:53 -0400	[thread overview]
Message-ID: <20130623115953.GA16193@thunk.org> (raw)
In-Reply-To: <loom.20130623T082353-563@post.gmane.org>

On Sun, Jun 23, 2013 at 06:29:18AM +0000, Felipe Monteiro de Carvalho wrote:
> 
> I am still very much interesting in knowing this! Are all groups flexible 
> groups when FLEX_BG feature is activated?
> 
> I found this image for how things relate to one another without flex_bg:
> 
> http://origin-ars.els-cdn.com/content/image/1-s2.0-S1742287612000357-gr1.jpg
> 
> Does anyone know if there is a simular image with flex_bg???

Historically, before flex_bg, the allocation bitmaps and inode tables
for a particular block group had to be located within that block
group, per the image that you've referenced above.

This had two difficulties.  The first is that every 128MB (assuming a
4k blocksize and the default/maximum number of blocks per block
group), there would be file system metadata, thus breaking up the
maximum contiguous free space available for data blocks.  The second
is that if e2fsck or resize2fs needed to relocate a metadata block, it
reduced the flexibility of where the new location of that metadata
block might be.

So the flex_bg feature relaxes this constraint.  So if we can put the
metadata blocks anywhere, where do we put them?  That's where
s_log_flex_bg_size in the superblock comes in.  This is a default
policy used by mke2fs and for online resizing where we try to put the
allocation bitmaps and inode table blocks at the beginning of a flex
group, where flex group N is defined as blocks falling within the
range (N * flex_bg_size) through (((N + 1) * flex_bg_size) - 1).

Note though that this is not a mandatory layout; there may be times
where e2fsck or resize2fs may need to change where these blocks end up
living.

The other thing which we do with this flex_bg layout is that it
influences ext4's inode and block allocation hueristcs.  For example,
ext4 will try to bias its allocation of directory blocks to try to
keep them within the first block group, and it will bias the
allocation of data blocks away from the first block group in a flex_bg
group.

Regards,

						- Ted

  reply	other threads:[~2013-06-23 11:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-12 12:20 Beginner questions about ext4 Felipe Monteiro de Carvalho
2013-06-23  6:29 ` Felipe Monteiro de Carvalho
2013-06-23 11:59   ` Theodore Ts'o [this message]
2013-07-01 15:23     ` Felipe Monteiro de Carvalho
2013-07-01 16:55       ` Theodore Ts'o
2013-07-10 16:13         ` Felipe Monteiro de Carvalho
2013-07-10 17:24           ` Theodore Ts'o
2013-07-11  7:37             ` Felipe Monteiro de Carvalho
2013-07-11 15:23               ` Theodore Ts'o
2013-07-15 10:20     ` Felipe Monteiro de Carvalho
2013-07-15 13:43       ` Theodore Ts'o
2013-07-15 16:09         ` Felipe Monteiro de Carvalho
2013-07-15 16:37           ` Theodore Ts'o
2013-07-15 17:55             ` Felipe Monteiro de Carvalho
2013-07-15 18:10               ` Theodore Ts'o
2013-07-15 18:18                 ` Felipe Monteiro de Carvalho
2013-07-15 18:59                   ` Theodore Ts'o
2013-07-16  6:14                     ` Felipe Monteiro de Carvalho

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=20130623115953.GA16193@thunk.org \
    --to=tytso@mit.edu \
    --cc=felipemonteiro.carvalho@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    /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.