I don't like the idea of significantly enlarging the inode structure
to support these sorts of features, particularly if only a small
percentage of the files on any given system will be using them.
(It seems likely to me that Unix/Linux sysadmins will continue to
use traditional Unix permissions bits wherever possible, and only
*resort* to ACL's (etc) when then *need* to do so.
One thought occurred to me: what if we only add a pointer to
a "resource fork" (not really much like the Apple/MacOS "resource fork"
-- so perhaps we should call it something different, like the
meta data field). I guess this would actually be a pointer to another
inode -- one normally had no directory entries (links). Then arbitrary
amounts of meta data could be encoded into the data on this other
"fork."
We're doing something like this for the linux-privs, although we're not
calling it a resource fork because it has all of the wrong
connotations. The ACL's which Remy is working on is also storing the
actual ACL information elsewhere (and in a clever way so that most of
the time, inodes with identical inodes can share ACL's so that we save
space on disk). So don't worry, we've thought about these sorts of
issues already.
As usual I'm speaking on a purely theoretical basis here. My real
question is: how were we planning on adding most of these extensions
to the fs'. It seems like I've read about a bunch of different patches
to ext2fs (from GNU HURD's "watchdog" file system objects to Andrew
Morgan's "privs" to several ACL's systems and a few logging and/or
journaling fs').
We're going to add them very carefully. :-)
A lot of people are argueing for a lot of different extensions, and
people may think I'm a close-minded S.O.B. for not jumping up and
accepting all of them right away. Stephen, Remy, and I are trying to
apply some architectural principles behind ext2's evolution, and we do
care about silly things like backwards compatibility, and robustness,
and that may mean that we don't accept all of these extensions right
away. It's why the compression code hasn't been completely folded in
yet, for example (although I have been talking to the e2compr folks, and
as a result of our discussions, the resulting design that does get
folded into the mainline kernel should be much better).
- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu