tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: tstile syndrome



On Sun, Aug 30, 2009 at 03:06:44PM +0100, Mindaugas Rasiukevicius wrote:
 > > > Yet another reason take vnode locking to the dump, cue objection
 > > > from Holland.
 > > 
 > > I still don't see why you think this is going to magically fix
 > > everything.
 > 
 > Why add word "magically"? BSD vnode locks demonstrated that they
 > fall in many issues as opposed to inode locking (e.g. SVR4 style
 > locking).

Such as? Please give clear examples. Moving the locks to below the VFS
layer does not change any of the ordering constraints or any of the
hard problems (vnode recycle, rename, etc.) but only forces cutting
and pasting 30 copies of what was previously FS-independent code into
every FS.

There are a number of severe defects in the current implementation,
such as the fact that most VOP calls are not symmetric with respect to
locking, but this has little to do with the architecture.

Also, do you (or any of the other people spouting this line) have any
concrete proposals for how the layered FSes will work in this
environment? Or do you plan to remove them all, or are you just waving
your hands?

 > IIRC, at least few more engineers, good engineers, agreed
 > about vnode locks in the past, on tech-kern.

References? All I remember seeing is a commonly expressed desire to
avoid imposing hierarchical tree locking on FSes that may not need it
for some reason (presumably because they're only passing requests over
the network) ... but while that's a nice idea it's not very workable.

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index