Date: Wed, 25 Aug 1999 11:35:18 +0930 From: Greg Lehey <grog@lemis.com> To: Terry Lambert <tlambert@primenet.com> Cc: 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: <19990825113518.D83273@freebie.lemis.com> In-Reply-To: <199908250152.SAA16323@usr01.primenet.com>; from Terry Lambert on Wed, Aug 25, 1999 at 01:52:38AM %2B0000 References: <19990825083036.Q83273@freebie.lemis.com> <199908250152.SAA16323@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 25 August 1999 at 1:52:38 +0000, Terry Lambert wrote: >>> I don't want to express an opinion about the need or otherwise >>> for mandatory locking, but I would appreciate a teensy >>> clarification of the problem domain: >>> >>> On Mon, Aug 23, 1999 at 05:43:45PM +0930, Greg Lehey wrote: >>>> To write a block to a RAID-5 device, you need to: >>>> >>>> 1. Read the old data into a temporary buffer. >>>> 2. Read the old parity data corresponding to the data into a >>>> temporary buffer. >>>> 3. XOR the two, storing the result in one of the temporary buffers. >>>> 4. XOR the result with the data which is to be written. >>>> 5. Write the data block. >>>> 6. Write the parity block. >>> >>> Are you suggesting that random user processes have to do all of >>> this every time that they access a vinum drive? >> >> Yes. > > This could also be accomplished with a volume access lock at the > CAM level. It could be, but it would introduce unnecessary waits. > 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. > 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. > 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). > 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? Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key 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?19990825113518.D83273>