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

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Mon, Jan 16, 2012 at 08:46:44PM +0000, David Holland wrote:
> On Mon, Jan 16, 2012 at 07:37:19PM +0100, Manuel Bouyer wrote:
>  > > > The fisrt change is to the buffer cache.
>  > > 
>  > > My first reaction is that I don't think it's a good idea to make major
>  > > changes to the buffer cache at this stage in a release cycle. It's not
>  > > exactly the most robust or stable code we have in the system.
>  > 
>  > On the other hand, changing the kernel ABI in the release branch
>  > is not a good idea either, given the state of the module subsystem ...
> 
> 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.

> 
> releng and/or core will need to rule on that but I don't think it's a
> good idea.
> 
> The buffer cache code is ratty, poorly structured, and full of races
> that may or may not have visible consequences. Any change to it could
> turn out to be unexpectedly disruptive, and we don't at this point
> have time to clean up if the changes turn out to make a mess.
> (Especially since the person who'd likely have to do the cleanup,
> namely me, is already oversubscribed right up to the branch deadline
> on other stuff. Which, not to put too fine a point on it, includes
> sorting out a previous mess.)
> 
>  > I wouldn't call this a major change. The alternative way (adding a b_type
>  > member to struct buf) is even less intrusive; if the alternative (*2())
>  > functions are not used it'll always be 0.
> 
> 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. 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.

> 
> 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.

>  > > (Also, you're aware that it isn't used for file data blocks, right?)
>  > 
>  > It depends on what you call "file data". Directory data blocks ends
>  > there AFAIK, as do symlink data blocks when the link's target doesn't
>  > fit in the inode.
> 
> Right. So, should extended attribute blocks go in the old buffer cache
> or should they be managed by uvm? This is another question we likely
> don't have time to address properly by the branch deadline.

Definitively the buffer cache, so it's covered by the journal. This is
metadata.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--