From owner-freebsd-hackers Tue Aug 24 16: 2: 9 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 891EC158B9; Tue, 24 Aug 1999 16:00:47 -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 IAA27553; Wed, 25 Aug 1999 08:30:38 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id IAA95473; Wed, 25 Aug 1999 08:30:36 +0930 (CST) Date: Wed, 25 Aug 1999 08:30:36 +0930 From: Greg Lehey To: Andrew Reilly Cc: Poul-Henning Kamp , Matthew Dillon , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman Subject: Locking in Vinum (was: Mandatory locking?) Message-ID: <19990825083036.Q83273@freebie.lemis.com> References: <19990823162813.I83273@freebie.lemis.com> <7569.935394460@critter.freebsd.dk> <19990823174345.J83273@freebie.lemis.com> <19990824105934.A82973@gurney.reilly.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <19990824105934.A82973@gurney.reilly.home>; from Andrew Reilly on Tue, Aug 24, 1999 at 10:59:34AM +1000 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 Tuesday, 24 August 1999 at 10:59:34 +1000, Andrew Reilly wrote: > Hi Greg, hackers list, > > 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. > I thought that access was mediated by a driver or server process. Sure, that's how they do it. It's a driver, not a server, and the top half runs in process context. > Isn't this process in a position to ensure the integrity of the > transaction without any help from locking mechanisms? No. But what we're talking about here has nothing to do with Vinum's locking, which is internal. > If some major maintenance utility needs to run on the raw device, > during which time the state is inconsistent as far as user processes > are concerned, isn't it sufficient to remove their read priveliges? What if the volumes are open? What if you don't want to upset the processes, just keep them away a little while you do your thing? While testing Vinum, I found a number of race conditions. Most lasted about 50 ms. I have to lock to prevent corruption, but nobody would notice the delay. 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