Subject: Re: split LFS vnode locks
To: None <perseant@hhhh.org>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: tech-kern
Date: 12/17/2002 13:44:32
> > currently, since lfs_markv have to acquire vnode locks,
> > lfs_reserve have to release vnode locks before wait for lfs_avail.
> > however, releasing locks in lfs_reserve isn't safe because
> > we can't keep the vnodes/inodees from modifying without holding the locks.
> >
> > i'd like to separate metadata (ie. block pointers) lock from vnode lock
> > so that lfs_reserve no longer need to release vnode locks as attached patch.
> > is it ok?
> 
> Moving lfs_reserve out of lfs_bwrite_ext is a good idea, but I have a
> suggestion regarding the proposed meta locks.  Do you ever use the new
> meta locks in a context that does not already require the segment lock?
> 
> Block pointers only change during write and file allocation, both of which
> already require the segment lock; this would obviate the new locks, and
> since the segment writer is already single-threaded, it might not be
> necessary for the segment writer to lock the vnodes at all---references
> would be enough.  If that worked, it would simplify the locking mess quite
> a bit....

sure.

i thought that without vnode locks, a block might be moved, segclean'ed and
overwritten while we're waiting for bread.  but now it is protected by getblk
i added recently in lfs_fakebuf.
i thought that the getblk in lfs_fakebuf is somewhat problematic and
it should be replaced by metalocks because lfs_avail_wait can be called
by lfs_bwrite_ext holding buffer.  but i changed my mind now.
there's no need of metalocks, at least for now.  lfs_bwrite_ext should be
fixed instead.  and probably we should have lfs_reservebuf or something
instead of calling lfs_availwait from lfs_bwrite_ext.

YAMAMOTO Takashi