Re: buffer cache & ufs changes (preliminary ffsv2 extattr support)

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Jan 16, 2012 at 10:39:45PM +0100, Manuel Bouyer wrote:
 > > Indeed. But that isn't really the question. The question is really
 > > whether we're past the date for brand-new feature proposals for
 > > netbsd-6... or at least ones that involve invasive changes.
 > 
 > No, the question is whenever we commit the needed bits now
 > for the feature to be pulled up without kernel API major change later,
 > or if we accept a kernel API major change in the branch after netbsd-6-0
 > is branched. "this won't ever be in netbsd-6" is not an option, I don't
 > think we can wait for netbsd-7 for this.

No, that's really not the question. It's been months that we've been
planning out what will and won't be done in time for -6. That process
finally converged and we got a firm schedule. Now you come along with
something major you've never mentioned during this whole time and it
just *needs* to get in at the last minute? Really, I don't think it
can or should.

I mean, I could cite a dozen or two other things that "ought" to be in
netbsd-6, for various definitions of "ought"... many of them much less
invasive and/or dangerous. They're not going to be. It's too bad, in
some sense, but it's already been too long since -5 was released and
some point one needs to stop and release the system one has, not the
system one would want if one just had another three (or six or nine or
eighteen) months.

I'm sorry if I sound testy and I'm really not trying to start a fight;
but we really do need to get this thing branched and shipped, and what
you're proposing could easily turn into a three-month delay (if it
more or less works) or six or more (if it cracks wide open).

 > > Changing the way the buffer cache is indexed is semantically intrusive
 > > even if it's not physically intrusive. While I think adding a type
 > > field to modify the block number is a good idea, for various reasons,
 > > it needs to be thought through, and it hasn't been yet and there isn't
 > > time to thrash it out fully before the branch deadline. Furthermore,
 > > there's the existing question of indexing by physical vs. virtual
 > > block numbers; that is not in any way a resolved issue and what you're
 > > proposing interacts directly with it, and this too needs to be thought
 > > through and there isn't time before the branch deadline.
 > 
 > Yes, and I don't think we need to wait for theses questions to be
 > sorted out to have ffs2 extended attributes.

Then figure out how to do ffs2 extended attributes without changing
the buffer cache. I'm sure it can be done, and without resorting to
gross hacks, either.

 > Even if the buffer cache
 > code is rototilled later, I don't think extended attributes or the new
 > type field will make it harder, and the code in HEAD and the netbsd-6
 > branch is allowed to diverge.

With all due respect, you also didn't think the quota proplib stuff
was going to make things harder; I've already put as much or more time
into straightening it out than it took to fix ufs_rename, and it's
nothing like done yet. I would like to avoid a repeat of that whole
experience, partly because it's an ineffective use of scarce resources
(namely, developer time, both yours and mine) and partly because such
situations breed resentment and infighting.

The buffer cache code desperately needs a major rework. Ideally this
should be done in its entirety before anyone tries to make any new
semantic extensions to it or add any new functionality, to avoid
accidentally making the code worse than it already is and to avoid
adding new requirements to the logic that might turn out to be
impossible or vastly expensive to implement sanely.

If we really need to add features or extend the behavior before the
rework can get done, it's absolutely essential that all of the
ramifications be sorted out in advance and chewed over by as many
people as possible.

I'm sure someone's going to respond to say I'm being alarmist (or at
least think it) -- maybe I am, but the buffer cache, along with other
similar/related code (think genfs_putpages, and also the syncer) is
among the most subtle and delicate in the (or any) kernel. The
implementation in NetBSD is in no way well structured or robust; the
only reason it works at all is that it's been in production all this
time and any regressions that appear get reverted. I also had the
interesting experience of doing a new implementation of roughly the
same design a couple years back; even when done carefully and tidily
and stuffed full of assertions there are many subtle ways for it to go
wrong... many of which I'm sure exist as unfixed problems in the
NetBSD code. We *know* there's a certain background level of weird
unexplainable and unrepeatable filesystem bugs. A while back I tracked
one of those down, because it produced a panic with clear symptoms,
and traced it to race conditions involving buffer flags.

Fixing this up has been basically second on my urgent priority list
after ufs_rename, which had much worse consequences. I haven't
embarked on it yet (even though ufs_rename is now fixed) because there
wasn't any way it was going to be done in time for -6, and a major
open-ended rototill is just not something you start out on when people
are talking about branching a release, which as I noted above we have
been since sometime last spring.

 > > Meanwhile, adding a whole set of extra functions instead of doing
 > > things properly with a massedit is highly undesirable; not only is it
 > > ugly but it leaves us unable to tidy the extra functions away in HEAD
 > > after branching, which is bad... unless we want to vastly complicate
 > > any pullup that goes near the buffer cache, which would be worse.
 > 
 > A massive change to the buffer cache code won't be pulled up to netbsd-6
 > anyway (one of them being the mess it would cause for modules) so
 > the code will not be the same in netbsd-6 and HEAD anyway.

Eventually, yes. But certainly not until 6.0 is released, and also not
gratuitously.

-- 
David A. Holland
dholland%netbsd.org@localhost