Re: don't use wapbl (-o log) on / (/dev)

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

On Sun, Feb 15, 2009 at 01:41:14PM -0500, Steven M. Bellovin wrote:
 > And where does the wapabl come in?  The file system where /dev exists?
 > Strange...

Yes. This keeps recurring with different pairs of fs types; the
ultimate cause is some kind of structural problem that doesn't isolate
filesystems from one another well enough.

I'm inclined to think a big part of it is that the buffer cache tries
(to support LFS) to be virtually indexed and never physically indexed;
that is, all buffers belong to vnodes and file offsets rather than
devices and device offsets. The problem is that this doesn't work for
blocks that don't belong to files, and so they get attached to the
vnode of the device the fs is mounted on, so the "file" is the device
and the offset is the device offset. Trouble is, that vnode belongs to
the root fs, and so we end up calling the root fs's vnode ops or vfs
ops to work on the buffers. I think. (I haven't traced this all
through yet and I may be missing something.)

While in theory we could special-case all handling of buffers
belonging to block devices, that requires a lot of caution in a lot of
places and is not going to be maintainable as the system evolves...
even assuming we can find all the relevant places, which given that
the problem keeps reappearing doesn't seem to have been the case in
practice.

I think the buffer cache needs to be restructured so it can be either
virtually or physically indexed. This is going to be a big hassle.

(Note that "remove LFS" is not the answer. Any fs that does online
rearrangement of any kind needs a virtually-indexed cache.)


[followups to tech-kern]
-- 
David A. Holland
dholland%netbsd.org@localhost