Date: Sat, 17 Jun 2000 05:40:15 -0700
From: Hans Reiser <hans@reiser.to>
There is a guy who wrote an online resizer for ext2. I have no idea
whether it is good or trash. He has been trying to get it into the
kernel since early or mid 2.3. Alan Cox is being quite helpful to
the guy. The problem is that the reasonable thing to do is to have
one of the ext2 maintainers review his code and verify that they are
comfortable with it and it is good code. Why is this a problem?
Well it seems that the maintainers are busy with attending
conferences and their own code right now. They have been busy like
this for more than 6 months, and as a result this rather useful
sounding functionality is very likely to miss 2.4. They haven't any
idea whether it is good code or not, they haven't bothered to read it
for 6 months.
.... and now, for the rest of the story.
Andreas Dilger has asked us to integrate a patch which makes it easier
for him to maintain his on-line resizing patch. It moves a lot of code
around from ext2_read_super() to a new function. It is supposedly
doesn't change any lines of codes, but it is a very large patch, and so
it's painful to integrate. Given that it had no functional changes, I
gave it a low priority.
Given that other pieces of the kernel which I am responsible for (and
which are already in the Linux mainline) which have SMP race conditions
(/dev/random) or which give kernel OOPS when you open the device (the
rocketport driver), the gentle reader will perhaps excuse me for not
attending to a 200 line patch which added to functional changes, but
which carried the risk of potentially destablizing a critical piece of
the kernel. Remember, unlike Hans Reiser, I don't have a staff of a
dozen people working for me. While this means that sometimes my
bandwidth is a little limited, it has the advantage that I don't get
placed into conflict-of-interest situations where the desire to earn
enough support income to pay for my employees doesn't tempt me to push
for integrating non-bugfix changes during a code freeze.
To Andreas's credit, at no point did he come to me and ask me to
integrate patches that actually integrated the on-line ext2 resizing
code into the mainline kernel. And if he had, I would have told him
that we were in code freeze (even six months ago, we were in code
freeze), and that the ext2 filesystem is too critical to risk
destablizing it once we entered
2.3.99.
In fact, as far as I know, he was planning on maintaining the on-line
resizing patch as a separate patch, and was not trying to integrate it
into Linux 2.4. The first that I heard that there was some desire to
sneak the full on-line resizing functionality into Linux 2.4 came from
Hans Reiser.
The guy who wrote that ext2 online resizer probably won't approve of
this email I am writing, so don't blame him for it.
The cynical person might perhapos think that this might be a
Micheavillean attempt by Hans to try to manufacture this as an excuse to
get reiserfs into the kernel. ("See, you let ext2 have changes, clearly
the code freeze doesn't have any meaning so you should let reiserfs
in!"). The more charitable explanation is that there is a fundamental
philosophical disagreement over what "code freeze" means, and what
levels of reliability and code maturity is required before letting
filesystem code into production use.
I repeat, as far as I know Andreas has never advocated that we try to
make fundamental functional changes to the ext2 code at this late date.
Only Hans seems to be strongly argueing for this. Why? I will leave it
to others to speculate; but ext2 isn't even his filesystem.
- Ted
-
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 : Fri Jun 23 2000 - 21:00:16 EST