From owner-freebsd-hackers Tue Aug 24 19: 7:35 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 65DF8152E6; Tue, 24 Aug 1999 19:06:54 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id LAA28473; Wed, 25 Aug 1999 11:35:20 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id LAA01659; Wed, 25 Aug 1999 11:35:19 +0930 (CST) Date: Wed, 25 Aug 1999 11:35:18 +0930 From: Greg Lehey To: Terry Lambert 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> References: <19990825083036.Q83273@freebie.lemis.com> <199908250152.SAA16323@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199908250152.SAA16323@usr01.primenet.com>; from Terry Lambert on Wed, Aug 25, 1999 at 01:52:38AM +0000 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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