On Sun, 15 Dec 2002, YAMAMOTO Takashi wrote:

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

That's something you have to live with. If you have to sleep, you have to
be ready for the world to have changed when you wake up.

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

I don't know enough about lfs to understand exactly the problem, but I
think this won't work.

You CAN NOT sleep with a vnode lock held.

lfs_reserve() calls tsleep, thus it MUST unlock the vnode.

There is no way around it.

Please forgive the vehemence I have on this subject; it is not directed at
you, but at the concept. :-)

If you _do_ sleep with a vnode locked, you start what Kirk called, "the
race for root." If anything tries to do a name lookup on the node that's
sleeping (say for a stat or some such, say as part of an ls -l), then the
parent directory's locked until you're done & the parent thread is woken.
If something does a name lookup through the parent directory, the parent's
parent is now locked. So and so on until you've locked the root vnode.
Then you've stalled any and all name lookup until you're all done. Given
how often processes do name lookups, you've frozen the system.

While you could create a separate lock for the block lists, you still
couldn't sleep with the vnode lock held, so I'm not sure if it'll do what
you want.

Take care,

Bill