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 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
