Linux-kernel mailing list archive 2000-06,: Re: 2.4 Features

# Re: 2.4 Features

Peter T. Breuer (ptb@it.uc3m.es)
Tue, 8 Feb 2000 21:08:00 +0100 (MET)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: david parsons: "Re: Source Code Release of NWFS 2.0 for 2.2/2.3/2.4"
- Previous message: Jakub Jelinek: "[PATCH] LFS RLIMIT_FSIZE (in blocks)"

"A month of sundays ago Theodore Y. Ts'o wrote:"
> From: "Peter T. Breuer" <ptb@it.uc3m.es>
> Date: Tue, 8 Feb 2000 00:59:50 +0100 (MET)
>
> The drawback is that one has to remember to distribute patched e2fsck.
>
> I think things would be clearer if e2compr appeared as a separate
> file system type, requiring mount -t e2c, for example. Then it
> could never be confused with ext2/3, and one would explicitly
> require a separate fsck.e2c executable instead of a patched e2fsck.
>
> The e2compr patches should be using a ext2 superblock compatibility bit
> to indicate that it is using a feature that might not be supported by
> older (or in this case, mainline) utilities.
>
> There's no real point in changing the filesystem type. If you don't

The reason I suggested it was not technical, but "marketing". The only
reason compression has not been in the kernel has been because it has
been deemed bad public relations. There exists the obvious possibility
that failures in a compressed ext2 would have been attributed by the
naive user to failures in "the linux file system", sullying the good
reputation of the aforementioned entity. I buy that public relations
argument.

> have the patched e2fsck, e2fsck will fail with an error message stating

Failure - with any sort of message or not - is a no no anyway. It's the
bad press from naive users that manage to fsck up that is the problem.
Or from sophisticated ones that want to pretend that there is a problem.

> that the filesystem is using an unsupported feature, and so e2fsck will
> refuse to touch it lest it damage the filesystem. If you change the
> filesystem type, then if you don't have the patched e2fsck, fsck will
> fail. Either way, the right thing should happen.

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.
:-) Please help keep these issues separate, where they belong. There
isn't enough room in e2fsck for all the possible variants of e2fs.

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/

- Next message: david parsons: "Re: Source Code Release of NWFS 2.0 for 2.2/2.3/2.4"
- Previous message: Jakub Jelinek: "[PATCH] LFS RLIMIT_FSIZE (in blocks)"