"A month of sundays ago Theodore Y. Ts'o wrote:"
> From: "Peter T. Breuer" <ptb@it.uc3m.es>
> Date: Tue, 8 Feb 2000 21:08:00 +0100 (MET)
>
> Yes, but I think the latter is the right marketing decision. And I am
> sick of patching e2fsck. I have patches for e2compr, patches for ACLs,
> patches for I don't know what. It's tough to keep them all working
> together. Sometimes I can't and I have to beg the maintainers of the
> patches to just _stop it_ or at least use the same version of e2fsck.
>
> But what you're suggesting simply doesn't make sense, and doesn't solve
> your problems.
It doesn't solve ALL problems, but yes, it solves mine!
E2compr's not going to get in the kernel at this rate. The only weighty
reason behind that is its status as a patch on ext2, which makes
companions of several considerations that could live happier lives
separated. So: separate them.
> There are patches for e2compr, patches for ACL, patches
> for capability support support, and so on. This causes a combinatoric
> explosion of possible combinations.
As I recall, I am trying to hold down the three you mention at least.
But their statuses are very different. E2compr is stable, near as
counts. It deserves to be recognized as such. If somebody wants to mix
(an) ACL on top of E2compr, let them patch e2compr with patches made for
e2compr instead of patching ext2fs for e2compr, then patching the result
with patches made for plain e2fs and fixing the conflicts.
It's a simplification, not a complication. It only requires that
e2compr make itself into a separate entity, which the maintainer can do
in two shakes of a lambs tail!
One can provide an e2fslib.o for the shared parts. Or get together to
see if hooks can be left in ext2fs that would allow e2compr to work as a
dynamic add-on facility. But I don't think that's remotely possible.
> Did you want the filesystem that supports e2compr and ACLs? Just
> e2compr alone? ACL's alone? E2compr and capabilities? Capabilitiy and
> ACL's? There are 8 possibilities, and as we start bringing up new
> combinations, there will be 16, 32, etc. So are we going to have names
> like e2c-acl? e2c-acl-cap? e2-acl-cap? etc. Ridiculous!
Yes. So what is the solution? I proposed that as compression is the
nasty word, that it be hived off into a separate file system name so
that nobody could ever blame ext2fs for it. But are you saying that
you intend that all these add-ons should someday be handled as
"extended attributes"? That's an undertaking that would destabilize
ext2fs in itself. So it won't happen, will it?
> That's why we have the compatibility bitfield in the superblock.
But it doesn't _help_. It's a nay-sayer at present. It could be used
to redirect ext2fsck to call a separate fsck?
> Note that the *reason* why most of these patches haven't been merged
> into the e2fsprogs is that it's not yet 100% certain that the format
> filesystem is stable yet. You have to make patches because I want to
> make it 100% clear that this is beta code, and not something which is
> fully supported.
The e2compr stuff is not beta code. It's at least as stable as ufs,
minix, vfat, resierfs, and all the rest. The only thing it's not as
stable as is ext2.
> If it turns out that some change is needed to more
> efficienctly or robustly support ACL or Capabilities, there may not be
> (almost certainly will not be) backwards compatibility with the old
> format. Marketing and beta don't go together.....
But this attitude is only outfacing itself. The result is that other
people can say: look, linux doesn't have compression, linux doesn't
have acls, linux doesn't have cababilities. If you say that you can
patch, they can point and ask for a single example of a distribution
that has been capable of patching for all these.
Compression is stable. Let it have its own name, disassociated from
ext2fs. Then the ACL writers can take it into account if they want to,
by writing a patch for it. If in the future a way is found to house it
within ext2fs again, then leave that to the future.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:15 EST