Date: Wed, 25 Aug 1999 02:31:09 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: grog@lemis.com (Greg Lehey) Cc: tlambert@primenet.com, a.reilly@lake.com.au, phk@critter.freebsd.dk, dillon@apollo.backplane.com, hackers@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu Subject: Re: Locking in Vinum (was: Mandatory locking?) Message-ID: <199908250231.TAA18311@usr01.primenet.com> In-Reply-To: <19990825113518.D83273@freebie.lemis.com> from "Greg Lehey" at Aug 25, 99 11:35:18 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I think what people are missing here is that Vinum, when doing > > software RAID, is implementing a type of namespace escape, only > > it isn't a standard namespace escape. > > Interesting terminology. I think you've lost most people already. I hope not. It's not that hard a concept. You can hide filesystem objects from an upper layer, or you can "fold" directories. It's the idea of multiple views: hiding: folding: view 1: /foo/fee/.quota /xxx/data/yyy/data <-- data fork /foo/fee/bob /xxx/rsrc/yyy/rsrc view 2: /foo/fee/bob /xxx/yyy <-- data fork //rsrc//xxx/yyy <-- resource fork I.e.: trivial. > > Because this escapes the whole file, it is _not_ like the Vinum > > usage, which needs to escape parity bits on a block device. The > > Vinum usage needs to prevent access to the file range covered by the > > parity bits, rather than merely protecting the parity bits. > > Correct. I lock a stripe at a time. Again, I think that, even with a user space daemon, you really don't want to use an fcntl mechanism to deal with this. I think you really want an ioctl() against a device file, instead. > > It seems to me that this is a proper application of mandatory > > locks. > > Sure. It also has nothing to do with the userland file locking I was > talking about in the previous thread. > > > For the use proposed by Vinum, however, fcntl() based mandatory > > locks are probably not the proper tool. > > Vinum isn't proposing fcntl-based locks. I was looking at them for a > specific application; Vinum has always had its own locking mechanism > (see sys/dev/vinum/vinumlock.c). OK, it wasn't clear that you had jumped boats. > > This is because you can only apply locks to devices that have a > > VOP_ADVLOCK on their backing store, and which use the VFSOPS > > based fileops structures. > > > > For the same reason that Linux user lament the inability to > > place advisory range locks on special files in FreeBSD, so, too, > > would Vinum be unable to place mandatory locks through that > > same mechanism against special files in FreeBSD. > > > > To correct this to allow it to work would require hanging the > > locks off of the vnode, instead of hanging them off the backing > > object (I have been suggesting -- and providing patches for -- > > this for literally years). > > Can you point me to the patches again? These particular ones are probably outdated by some more recent ones by Mike Hancock, but they should be in the mondo patch set that was intended to allow NFS server locking. It's in my home directory on freebsd.org. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908250231.TAA18311>