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 g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message