Alan Cox wrote:
> > The code duplication in fs/reiserfs/ is a bug. But does this bug harm anything
> > but maybe somewhat performance? If it does not harm, there is no reason for
>
> It does because if it goes in then nobody will get around to cleaning it up
> promptly.
>
> > reiserfs not to make in pre-2.4 kernels, because those bugs can be fixed. The
> > win is at least an as EXPERIMENTAL marked journaling filesystem, and people who
>
> Stop a moment
>
> IF reiserfs is marked as experimental then people shouldnt be using it for
> a production system - yes
>
> Now if that is the case merging in 2.5, or having it as an add on patch some
> vendors and many others will apply is no problem
Er... so why do I have "PCI bridge optimization" "VIA82C568" "ipportfw masq support"
"IPv6 protocol" "Bridging" "QNX filesystem" "Apple Macintosh filesystem" "frame
buffer devices" (you see, a compilation from a 2.2.14 kernel) and many more marked as
experimental? Because they all do not really belong to 2.2, but to 2.3 (or maybe
2.5)? Or because they proved usefulness and stability for a limited group of users
and are deemed to be useful for others.
I always saw an "experimental" mark as a way to say "this is a fine feature, use it
if you want, but be warned that it still may contain bugs", not to say "some students
played with the abilities they got the last weeks, they want to share their results
with you". If it's the first case: reiserfs (for 2.2 at least) is definitely of value
for most of us, and it showed stability. And if it's the second case, it would
obvious that reiserfs could get in.
You say that an fs marked as experimental should not be used in production
environment. This might be you point of view.
<LongExample>
We, for example, use reiserfs for production because there is a need to come up
quickly after an unclean shutdown. We still have a second disk where everything from
the reiserfs partition is mirrored to, for the case that there is a bug in reiserfs
corrupting our data. But, just for annotaion, the opposite occured. If a box with
ext2 was shut down unclean, we often had files, which were open at power cut time,
deleted. This hit the users which were using the server most (because it were their
registry files which got deleted). Reiserfs did not show that behaviour.
</LongExample>
Other people use it in production because its features are needed in production.
Because they are _needed_, users should have the _choice_ to decide wether it is
better to have some hours downtime at prime time or wether there may be unresolved
issues, because the fs ist just new. From the users point of view, reiserfs has
finished its "narrow" beta stage (for a limited number of users), it should start its
"wide" beta stage (for a limited number of users up to 6 billion ;-)).
I understand why some important people are against inclusion into 2.4. Most of us are
striving for perfection, and we know that reiserfs namei.c is not optimal. But not
being optimal does not necessarily mean not being good (it only means not being
best). But we also know that the kernel development process is not the best. The next
jump-in-point is 2.6 or 3.0 (whatever comes after 2.5) in 12..18 months. It would not
honour being good (but not best) when reiserfs is not included in 2.4 and maybe
marked as experimental.
Let 90% of the users decide wether they need a somewhat guaranteed startup time below
2 minutes and other features offered by reiserfs or wether they need stability more
proven without reiserfs than with. They still can say "no" after being warned of
sub-optimality, possible instability, data loss and earthquakes in the kernel confing
menu. But others will say "That's what I've been waiting for, this feature is worth
for me and the Linux community to be a beta tester." Just because we do not know most
of those people, we should not take their opportunity of trying out and using a
demanded feature away.
Xuân. :o)
-
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 : Wed Mar 15 2000 - 21:00:25 EST