From: "Theodore Ts'o" <tytso@mit.edu>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Andreas Dilger <adilger@clusterfs.com>,
Takashi Sato <sho@bsd.tnes.nec.co.jp>,
cmm@us.ibm.com, linux-kernel@vger.kernel.org,
ext2-devel@lists.sourceforge.net,
Laurent Vivier <Laurent.Vivier@bull.net>
Subject: Re: [Ext2-devel] [PATCH 1/2] ext2/3: Support 2^32-1 blocks(Kernel)
Date: Mon, 20 Mar 2006 23:03:05 -0500 [thread overview]
Message-ID: <20060321040305.GB8257@thunk.org> (raw)
In-Reply-To: <1142894283.21593.59.camel@orbit.scot.redhat.com>
On Mon, Mar 20, 2006 at 05:38:02PM -0500, Stephen C. Tweedie wrote:
> But it's probably not too late. I would expect that the vast majority
> of filesystems won't have any inodes that have fully-occupied xattr
> space. It would be easy enough to define a new flag that indicates that
> there is always X amount of space reserved for inode fields, and to set
> that in fsck if all inodes on the fs obey that restriction. Then it
> just comes down to picking a number X that is likely to satisfy all the
> short-term demands for new inode fields.
Yes, that's what I'm proposing that we do. My original plan was to
use an incompat flag that would guarantee that there would be enough
space for likely short-term new inode fields, but perhaps it doesn't
have to be an incompat flag. At least in theory it could be a compat
flag, and then we release a new e2fsprogs which enforces the guarantee
that at least that much space is reserved in every single inode, and
offers to remove one or more EA's in order to satisfy that guarantee.
There is a chance that someone who has a filesystem with the compat
feature enabled, a kernel has the support for high-resolution
time-stamps, and an old e2fsprogs will get screwed, but only if the EA
space is totally filled up. But maybe that's an acceptable risk, and
the worst that will happen is that make(1) will get confused.
> I think we're probably early enough in the adoption of large inodes that
> we don't have to make that compromise, and we can reserve some space for
> guaranteed use by inode fields with a single minimally-invasive compat
> change (say, a flag enabling a field in the superblock which defines how
> many bytes we can always safely use for extended inode fields.)
Ah, it sounds like you're thinking the same thing I am. OK, that
seems like a reasonable compromise. We are taking a bit of a
shortcut, but it seems reasonable to assume that distro's will have
the right version of e2fsprogs if they want to use this feature; if
they don't users won't be able to enable the new compat flag anyway,
which means the chances of the user noticing a real problem is pretty
low.
- Ted
next prev parent reply other threads:[~2006-03-21 4:03 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-15 12:39 [PATCH 1/2] ext2/3: Support 2^32-1 blocks(Kernel) Takashi Sato
2006-03-15 12:56 ` [Ext2-devel] " Laurent Vivier
2006-03-16 2:19 ` Mingming Cao
2006-03-16 12:11 ` Takashi Sato
2006-03-16 13:53 ` Theodore Ts'o
2006-03-16 18:35 ` Andreas Dilger
2006-03-16 21:26 ` Theodore Ts'o
2006-03-16 22:59 ` Andreas Dilger
2006-03-18 17:07 ` Theodore Ts'o
2006-03-20 6:36 ` Andreas Dilger
2006-03-20 22:38 ` Stephen C. Tweedie
2006-03-20 23:48 ` Andreas Dilger
2006-03-21 17:05 ` Stephen C. Tweedie
2006-03-21 18:38 ` Theodore Ts'o
2006-03-21 19:47 ` Stephen C. Tweedie
2006-03-21 20:40 ` Andreas Dilger
2006-03-21 20:16 ` Alfred M. Szmidt
2006-03-21 23:05 ` Olivier Galibert
2006-03-21 23:35 ` Alfred M. Szmidt
2006-03-25 14:51 ` cascardo
2006-03-26 16:27 ` Andreas Dilger
2006-03-27 19:59 ` Stephen C. Tweedie
2006-03-27 20:36 ` Alfred M. Szmidt
2006-03-27 19:55 ` Stephen C. Tweedie
2006-03-27 20:05 ` Alfred M. Szmidt
2006-03-27 20:40 ` Stephen C. Tweedie
2006-03-28 0:14 ` cascardo
2006-03-21 20:26 ` Andreas Dilger
2006-03-21 4:03 ` Theodore Ts'o [this message]
2006-03-17 9:35 ` Laurent Vivier
2006-03-19 2:20 ` Theodore Ts'o
2006-03-20 10:11 ` Takashi Sato
2006-03-26 3:01 ` Theodore Ts'o
-- strict thread matches above, loose matches on Subject: below --
2006-03-26 22:15 Chuck Ebbert
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=20060321040305.GB8257@thunk.org \
--to=tytso@mit.edu \
--cc=Laurent.Vivier@bull.net \
--cc=adilger@clusterfs.com \
--cc=cmm@us.ibm.com \
--cc=ext2-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=sct@redhat.com \
--cc=sho@bsd.tnes.nec.co.jp \
/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