> I'm not hearing, "I want to do X, but can't because of Y so I
> want to change Y to Z." Those comments don't sound like the right way to
> start out changing things.

lfs sometimes need to wait for cleaning before starting
an actual operation.  it can't be done cleanly,
because vnode lock is already held by upper layer.

it's better to allow several operations for a directry concurrently.
esp. for remote filesystems like nfs.  it's not possible with mandatory
vnode locks.

so i want to change vnode locks (back) to advisory.
or migrate to filesystem internal locks completely.
(actually i don't want to do such changes for now.
i'm just talking about the ideal world.)

i thought that i said all of the above somewhere.
sorry if it was not clear to you.

> If we didn't do the locking externally, we pretty much lock as soon as the 
> write starts, and unlock before exiting. Seems about the same to me. Yes, 
> we spend a few cycles fewer w/o the lock, but I don't think that, in and 
> of itself, is much of a difference.

consider synchronous writes.
you can implement a simple VOP_WRITE as the following.
	1. copy data to page cache and update some incore data.
	2. start disk i/o.
	3. wait for the i/o completion.
for this filesystem, you don't likely want to prevent VOP_READ
during 2 and 3.

YAMAMOTO Takashi