From: Theodore Ts'o <tytso@mit.edu>
To: TR Reardon <thomas_reardon@hotmail.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Reserved GDT inode: blocks vs extents
Date: Fri, 19 Sep 2014 12:36:49 -0400 [thread overview]
Message-ID: <20140919163649.GQ26995@thunk.org> (raw)
In-Reply-To: <BAY406-EAS150EB9E4098E2894ADA30B7FDB40@phx.gbl>
On Fri, Sep 19, 2014 at 11:54:39AM -0400, TR Reardon wrote:
> Hello all: there's probably a good reason for this, but I'm wondering why inode#7 (reserved GDT blocks) is always created with a block map rather than extent?
>
> [see ext2fs_create_resize_inode()]
It's created using an indirect map because the on-line resizing code
in the kernel relies on it. It's rather dependent on the structure of
the indirect block map so that the kernel knows where to fetch the
necessary blocks in each block group to extend the block group
descriptor.
So no, we can't change it.
And we do have a solution, namely the meta_bg layout which mostly
solves the problem, although at the cost of slowing down the mount
time.
But that may be moot, since one of the things that I've been
considering is to stop pinning the block group descriptors in memory,
and just start reading in memory as they are needed. The rationale is
that for a 4TB disk, we're burning 8 MB of memory. And if you have
two dozen disks attached to your system, then you're burning 192
megabytes of memory, which starts to fairly significant amounts of
memory, especially for bookcase NAS servers.
If I would do it all over again, knowing what we know now, I'd
probably redesign the meta_bg layout somewhat to group block group
descriptors into chunks. But it's probably not worth it to add yet
another block group descriptor layout at this point.
Cheers,
- Ted
next prev parent reply other threads:[~2014-09-19 16:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-19 15:54 Reserved GDT inode: blocks vs extents TR Reardon
2014-09-19 16:36 ` Theodore Ts'o [this message]
2014-09-19 17:26 ` TR Reardon
2014-09-19 19:48 ` Andreas Dilger
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=20140919163649.GQ26995@thunk.org \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=thomas_reardon@hotmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox