Date: Wed, 25 Aug 1999 08:30:36 +0930 From: Greg Lehey <grog@lemis.com> To: Andrew Reilly <a.reilly@lake.com.au> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Matthew Dillon <dillon@apollo.backplane.com>, FreeBSD Hackers <hackers@FreeBSD.org>, FreeBSD Committers <cvs-committers@FreeBSD.org>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Subject: Locking in Vinum (was: Mandatory locking?) Message-ID: <19990825083036.Q83273@freebie.lemis.com> In-Reply-To: <19990824105934.A82973@gurney.reilly.home>; from Andrew Reilly on Tue, Aug 24, 1999 at 10:59:34AM %2B1000 References: <19990823162813.I83273@freebie.lemis.com> <7569.935394460@critter.freebsd.dk> <19990823174345.J83273@freebie.lemis.com> <19990824105934.A82973@gurney.reilly.home>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990825083036.Q83273>