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

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

hi,

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

actually filesystems can use any kind of numbers as buffer cache index
for their own vnodes.
i don't understand how you think it's related to the bug, tho.
the "structural problem" you mentioned exists as far as a filesystem
are backed by a VBLK vnode and the filesystem uses the VBLK node's
buffer cache, doesn't it?

YAMAMOTO Takashi

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