Date: Mon, 15 Nov 1999 01:15:55 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Eivind Eklund <eivind@FreeBSD.ORG> Cc: fs@FreeBSD.ORG Subject: Re: Killing WILLRELE Message-ID: <Pine.BSF.3.95LJ1.1b3.991115010552.5097A-100000@sv01.cet.co.jp> In-Reply-To: <19991109224553.G256@bitbox.follo.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Eivind, I agree with your preferred patches. The slight performance hit for operations like mknod and symlink isn't a worry. IIRC rename was one of those operations where you have to reaquire a ref/lock before return to be consistent with the sane semantics rule. This will also add some latency, but again for an op like rename I don't think it's an issue. Mike On Tue, 9 Nov 1999, Eivind Eklund wrote: > I'm looking at removing WILLRELE from the VFS specs, in order to get > more sane semantics before introducing many more VFS consumers through > stacking layers. I'm sending this as a 'HEADS UP!', a chance for > people to object, and to give a chance at an advance view. > > Note that the present set of patches has not been tested beyond > compilation; I'm reserving testing until after I've let people have > the chance to scream at me (as I don't see a point in testing the > changes unless people agree that they are a step in the right > direction). > > There are presently three VOPs that use it: > VOP_MKNOD > Uses this for the 'vpp' parameter (should be the return vnode > for the newly created node, I believe). The value is > presently unusable; depending on which FS you call, it it is > either set to NULL, set to point to a vnode (MSDOSFS), or just > kept the way it was. (Note that MSDOSFS will leak vnodes as > of today). > > I've been tempted to remove it, but am not entirely happy > about that, as I think it might be useful for some stacked > layers. Thanks to phk, I've been able to come up with patches > to fix it - but these will increase the cost of VOP_MKNOD() > (only slightly, I think, but I am not quite certain). > > The other alternatives are to remove the parameter, or to > break the layering around ufs_mknod (basically, re-implement > parts of VFS_VGET in it, and make it assume that it is only > used with ffsspecops and ffsfifoops. This is presently > correct, but introduces risk of breakage down the road.) Both > of these alternatives are slightly more efficient than my > preferred fix. > > Patches to make VOP_MKNOD use vpp normally are > http://www.freebsd.org/~eivind/vop_mknod_fixed.patch > It is possible that the NFS vp release would have been handled > by common code if I hadn't added special code there, but I > feel too uncomfortable around the NFS code/macros to try to > find out. > > Patches to just remove the parameter are at > http://www.freebsd.org/~eivind/vop_mknod_novpp.patch > > VOP_MKNOD has 5 callers. > > VOP_SYMLINK > Same use of WILLRELE as VOP_MKNOD. > > Returns trash in some cases, OK values in others; relatively > simple to fix, with Coda as the only complication. > > Patches to fix it are at > http://www.freebsd.org/~eivind/vop_symlink_fixed.patch > These will break Coda, which I'm planning to contact rvb about > how to solve if people agree that WILLRELE should die. > > VOP_SYMLINK has 3 callers. > > VOP_RENAME > WILLRELE on a bunch of parameters. Adrian Chadd is doing > several things to VOP_RENAME which is relevant to this, so I'm > keeping my hands off it for the moment. Hopefully, patches > should be available later in the week. > > > My next step along the sane semantics road will probably be to make > freeing of cnp's reflexive - looking at the code that is there now, > there looks like there are a number of bugs related to this at the > moment, and it certainly makes the code much harder to follow. > > Eivind. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95LJ1.1b3.991115010552.5097A-100000>