From: Theodore Tso <tytso@mit.edu>
To: Andreas Dilger <adilger@sun.com>
Cc: Alex Tomas <bzzz@sun.com>, ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [RFC] dynamic inodes
Date: Fri, 26 Sep 2008 18:26:32 -0400 [thread overview]
Message-ID: <20080926222632.GE8903@mit.edu> (raw)
In-Reply-To: <20080926201832.GG10950@webber.adilger.int>
On Fri, Sep 26, 2008 at 02:18:32PM -0600, Andreas Dilger wrote:
> I agree that replicating a GDT inode is probably the easiest answer.
> IIRC this was proposed also in the past, before META_BG was implemented.
> To be honest, we should just deprecate META_BG at that time, I don't
> think it was every used by anything, and still isn't properly handled
> by the cross-product of filesystem features (online resize, others).
Meta_BG is I think relatively well supported now, actually. More to
the point, the resize_inode feature doesn't work for filesystems with
more than 2**32 blocks, since indirect blocks don't work for such
filesystems. The assumption had always been that we would use meta_bg
to support online-resize for > 2*32 block filesystem, once we had
implemented on-line resize support for it.
> How do inode numbers affect the GDT blocks? Is it because high inode
> numbers would be in correspondingly high "groups" and resizing could
> be done "normally" without affecting the new GDT placement?
Yep. So inode numbers between 1 and (num_bg*inodes_per_bg)+1 are
"natural" inodes, and inodes above that would have to be "dynamic"
inodes where the GDT would be found in an inode.
> I was going to object on the grounds that the GDT inodes will become too
> large and sparse, but for a "normal" ratio (8192 inodes/group) this
> only works out to be 32MB for the whole gdt to hit 2^32 inodes.
I'm not sure what you mean by "sparse".... the would be just as tighly
packed, but just starting at 2*32-1 and growing down.
> The other thing we should consider is the case where the inode ratio
> is too high, and it is limiting the growth of the filesystem due to
> 2^32 inode limit. With a default inode ratio of 1 inode/8192 bytes,
> this hits 2^32 inodes at 262144 groups, or only 32TB... We may need
> to also be able to add "inodeless groups" in such systems unless we
> also implement 2^64-bit inode numbers at the same time.
Yeah, good point. The real fundamental question is whether we want to
try to support 2**64 inodes as a long-term goal. Past a certain
point, we would have to have inodeless groups if we support 2**48
physical blocks, but only 2**32 inodes, with or without dynamic
inodes.
- Ted
prev parent reply other threads:[~2008-09-26 22:26 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-24 11:46 [RFC] dynamic inodes Alex Tomas
2008-09-25 22:09 ` Andreas Dilger
2008-09-25 23:00 ` Alex Tomas
2008-09-25 23:29 ` Andreas Dilger
2008-09-30 14:02 ` Alex Tomas
2008-09-25 22:37 ` Andreas Dilger
2008-09-26 1:10 ` Jose R. Santos
2008-09-26 10:36 ` Andreas Dilger
2008-09-26 14:49 ` Jose R. Santos
2008-09-26 20:01 ` Andreas Dilger
2008-09-26 2:11 ` Theodore Tso
2008-09-26 10:33 ` Andreas Dilger
2008-09-26 14:33 ` Theodore Tso
2008-09-26 20:18 ` Andreas Dilger
2008-09-26 22:26 ` Theodore Tso [this message]
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=20080926222632.GE8903@mit.edu \
--to=tytso@mit.edu \
--cc=adilger@sun.com \
--cc=bzzz@sun.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).