Sorry I'm chiming in late on this. On Tue, Sep 01, 2009 at 04:32:04PM +0000, David Holland wrote: > 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. We will have code when someone's ready to commit. However I think that throwing hurdles out now is inappropriate. Having worked with our locking system (and ten years ago being the one who made layered file systems viable) and also having worked with SVR4-esque locking systems where all the locking's in the fs, I have to say I vote for the SVR4 style. > 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. Agreed. > 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? Layered fs's won't care, and/or can do the locking them selves. To the extent a layered fs pass an op on to a lower fs, that fs's locking will suffice. To the extent a layered fs needs its own locking, it can provide it itself and that will be fine. Take care, Bill
Attachment:
pgpr55VDq01DY.pgp
Description: PGP signature