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 [EMAIL PROTECTED] for PGP public key
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
