On Wednesday, 25 August 1999 at 1:52:38 +0000, Terry Lambert wrote:
>>> 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.
>
> This could also be accomplished with a volume access lock at the
> CAM level.
It could be, but it would introduce unnecessary waits.
> I think what people are missing here is that Vinum, when doing
> software RAID, is implementing a type of namespace escape, only
> it isn't a standard namespace escape.
Interesting terminology. I think you've lost most people already.
> Because this escapes the whole file, it is _not_ like the Vinum
> usage, which needs to escape parity bits on a block device. The
> Vinum usage needs to prevent access to the file range covered by the
> parity bits, rather than merely protecting the parity bits.
Correct. I lock a stripe at a time.
> It seems to me that this is a proper application of mandatory
> locks.
Sure. It also has nothing to do with the userland file locking I was
talking about in the previous thread.
> For the use proposed by Vinum, however, fcntl() based mandatory
> locks are probably not the proper tool.
Vinum isn't proposing fcntl-based locks. I was looking at them for a
specific application; Vinum has always had its own locking mechanism
(see sys/dev/vinum/vinumlock.c).
> This is because you can only apply locks to devices that have a
> VOP_ADVLOCK on their backing store, and which use the VFSOPS
> based fileops structures.
>
> For the same reason that Linux user lament the inability to
> place advisory range locks on special files in FreeBSD, so, too,
> would Vinum be unable to place mandatory locks through that
> same mechanism against special files in FreeBSD.
>
> To correct this to allow it to work would require hanging the
> locks off of the vnode, instead of hanging them off the backing
> object (I have been suggesting -- and providing patches for --
> this for literally years).
Can you point me to the patches again?
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
