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

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

On Mon, Jan 16, 2012 at 10:00:05PM +0000, YAMAMOTO Takashi wrote:
 > have you considered to separate the entity being cached from vnode?
 > iirc, irix called it "buffer cache target" or such.

That sounds like probably a good idea, but I need to think about it
more.

One of the things we need to be able to do is have both physical
(block numbers are device offsets) and virtual (block numbers are file
offsets) buffers. Currently we do this by hanging physical buffers on
the device vnode, but this has always created problems. Also for some
filesystems it may be necessary or desirable to be able to take a
virtual buffer and change it to a physical buffer, or to keep track of
both a virtual and physical identity for the same buffer at once. I
need to figure out if the latter is really necessary or not, and I
don't think it'll become entirely clear until I've gotten well into
hacking up LFS.

 > your vtruncbuf2 function seems to imply needs to have separate
 > v_dirtyblkhd/v_cleanblkhd for each types.

I don't see why and I don't think makes sense, at least in the long
term. The global buffer data structures hold buffers; they shouldn't
care what's in them or who they belong to. Any type field becomes part
of the identity of the buffer, though, and therefore part of the
lookup key; that's all vtruncbuf2 is doing, although a quick look at
the code suggests that it is not doing it efficiently and it may not
be doing it correctly.

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