Hi Peter.
As I'm now joint maintainer of e2comp, there should be no problems
with my commenting on this...
>>> 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!
If it does, then your problem isn't the one you've been describing in
this thread.
> E2compr's not going to get in the kernel at this rate.
Why on earth not? I'm certainly hoping to see it in the mainstream
kernel before too much more time passes...
> 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.
I don't see that as even approaching a valid reason.
>> 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.
Agreed.
> 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.
Agreed.
Likewise, the e3fs that Stephen Tweedie is working on can either be
against e2fs as it currently stands or against a version thereof that
includes e2comp. That patch currently works independantly of e2fs and
that's the way it should be as the resulting patch is clearly going to
be at least partially incompatible with e2fs. However, there is no
such argument in favour of e2comp being a separate file system.
> 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!
Can do, yes - but doing so would in my opinion be a bad idea, and for
that reason I have no intention of doing so.
> 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.
I don't see it as even being necessary.
>> 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?
The solution is simple enough: As the various patches become stable
enough to be relied on, merge them into the standard kernel. Nothing
beyond that is necessary.
I don't by any means know all of the patches against the e2fs file
system, but of the ones I do know, only e2comp is even close to being
ready for inclusion in the standard kernel. However, it's long past
time that e2comp was included therein in my opinion.
> 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.
Why is compression "the nasty word", as you put it? The equivalent is
certainly available for Windows 95 and Windows 98, as I use it on the
only system I run with Win95 on it. Look at http://www.zipmagic.com if
you don't believe me.
> But are you saying that you intend that all these add-ons should
> someday be handled as "extended attributes"?
Whilst they are under development, that's the ONLY sane way to handle
them.
> That's an undertaking that would destabilize ext2fs in itself.
> So it won't happen, will it?
It already does.
>> That's why we have the compatibility bitfield in the superblock.
> But it doesn't _help_. It's a nay-sayer at present.
Really? Please explain why.
> It could be used to redirect ext2fsck to call a separate fsck?
It probably could. All it would require is for e2fsck to have a
configuration file stating which binary to call for each combination
of the various patches.
What would make far more sense in my opinion is to distribute as
standard a version of e2fsck that can already handle those of the
various patches that are regarded as reasonably stable. As far as I
can tell, there's no valid reason why this hasn't been done, and if
there is, I'd love to hear it.
>> 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.
Ted: What exactly do you mean by "the format filesystem" ???
If you are referring to "the format of the filesystem", then as far as
the e2comp patch is concerned, that is essentially unchanged, as the
ONLY change is that the file will take up less blocks than its
UNCOMPRESSED size indicates. Were this not the case, then it would not
have been possible to produce the patch in the first place.
>> 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.
To put it bluntly, if the e2comp patch is beta code, then so is the
entire Linux kernel. I for one don't believe the label "beta code" can
honestly be applied to either at this time.
> The e2compr stuff is not beta code.
Very true.
> It's at least as stable as ufs, minix, vfat, resierfs, and all
> the rest.
It's certainly more stable than several of the file systems that have
been accepted into the kernel, and less controversial than some of
them appear to be.
> The only thing it's not as stable as is ext2.
I can't say that I agree with that. Unless the comments Linus has been
making in the Linux-Kernel mailing list recently are rubbish, some of
the recent 2.3 series changes to memory management have made ext2 less
than stable, and several of the 2.3 series kernels are effectively
unusable as a result...
I will add that I have no direct experience of this as I don't run the
2.3 series kernels on my production machines and those comments had
been specifically directed by Linus at the 2.3 series kernels. I can
therefore only presume that he knew what he is talking about when he
made those comments.
>> 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.
Linus made it clear some time ago that ANY time a file system changed
in ways that meant that it could no longer access older formats, it
would be given a new name. That's the reason why ext became ext2 in
the first place, and also why ext3 has its own name. As a result, that
argument is a non-starter.
>> Marketing and beta don't go together.....
Oh yes they do - I can easily name three products that have been
widely marketed successfully that are clearly all beta grade products:
1. Windows 95
2. Windows 98
3. Windows NT.
However, say "Honest marketing and beta don't go together" and I would
gladly agree with you....
> 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.
If MacroHard had any sense, they would have done just that some time
ago.
> Compression is stable. Let it have its own name, disassociated
> from ext2fs.
Better still, let's get it merged into e2fs where it belongs. That
way, we can do precicely what Linus has said he wants: Get it in wide
circulation so any problems can be located and ironed out.
> 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.
The only place it belongs is inside of e2fs in the first place, with
the less stable patches being against the result, and not as it
currently stands.
Best wishes from Riley.
* Copyright (C) 1999, Memory Alpha Systems.
* All rights and wrongs reserved.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/
-
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