Date: Mon, 23 Aug 1999 17:43:45 +0930 From: Greg Lehey <grog@lemis.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: 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: Re: Mandatory locking? Message-ID: <19990823174345.J83273@freebie.lemis.com> In-Reply-To: <7569.935394460@critter.freebsd.dk>; from Poul-Henning Kamp on Mon, Aug 23, 1999 at 09:47:40AM %2B0200 References: <19990823162813.I83273@freebie.lemis.com> <7569.935394460@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 23 August 1999 at 9:47:40 +0200, Poul-Henning Kamp wrote:
> In message <19990823162813.I83273@freebie.lemis.com>, Greg Lehey writes:
>
>>>>> Why should it be made unavailable ?
>>>>
>>>> So that certain multiple accesses can be done atomically.
>>>
>>> You don't need that. You initialize a index to 0, and whenever the
>>> sector with that index is written, you increment it.
>>>
>>> At any one time you know that all parityblocks <= your index
>>> are valid.
>>
>> Sure, that's pretty much what I do in the situation you're thinking
>> about. But it won't work without locking. Take a look at
>> vinumrevive.c and vinumrequest.c.
>
> I still don't see the need for mandatory locking, or locking out
> user access in general...
I'll try to explain, using a different example, since I'm not quite
sure where my rebuild stuff is going yet.
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.
Consider what happens if a second request which refers the same parity
data comes in during this business:
1. Read the old data into a temporary buffer.
1a. Read the old data into a temporary buffer.
2. Read the old parity data corresponding to the data into a
temporary buffer.
2a. 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.
3a. XOR the two, storing the result in one of the temporary buffers.
4. XOR the result with the data which is to be written.
4a. XOR the result with the data which is to be written.
5. Write the data block.
5a. Write the data block.
6. Write the parity block.
6a. Write the parity block.
The parity data read at (2a) will be wrong. It won't know of the data
block to be written at (6). If the volume becomes degraded, it may no
longer know about the first transaction.
For this, we don't need fcntl locking: it would be too slow, and it's
all done in the kernel anyway. In userland, we'd use a different
example:
I make a number of financial transactions over the Internet. In
each case, the system checks my account balance, transfers the money
and deducts it from my account:
1. Check balance.
2. Perform transfer.
3. Write updated balance back.
Again, if we have two concurrent transactions, we stand to gain money:
the updated balance is likely not to know about the other transaction,
and will thus "forget" one of the deductions.
Now I suppose you're going to come and say that this is bad
programming, and advisory locking would do the job if the software is
written right. Correct. You could also use the same argument to say
that memory protection isn't necessary, because a correctly written
program doesn't overwrite other processes address space. It's the
same thing: file protection belongs in the kernel.
>>>> I'm a little surprised that there's any objection to the concept of
>>>> mandatory locking.
>>>
>>> Too many of us have had wedged systems because of it I guess...
>>
>> Strange, I've probably used it more than anybody here, and I've never
>> had a wedged system. Of course, you need to use it appropriately.
>> 'rm' can be a lethal tool :-)
>
> Well, maybe you were more lucky, I've had my share of troubles, and
> I think the very concept stinks...
You and Garrett. I've never heard this from *anybody* else. The
general opinion I've heard until now was that the lack of mandatory
locking was a significant weakness in BSD.
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?19990823174345.J83273>