On Wednesday, 25 August 1999 at 18:25:31 +0000, Terry Lambert wrote: >>> And how many programmers with nearly (or more than) two decades of UNIX >>> experience it takes to convince someone it really is useful. > > Har! 8-). > >> I must say, I'm really amazed at some of the opinions that have been >> voiced in this thread. Of course, that's all they are, and they show >> the origins of their owners. > > Har again! 8-).
I continue to be amazed. That's why I've been keeping out of this discussion. >> Any system with multiple concurrent accesses requires locking. Only >> UNIX uses advisory locking. It almost does the job, so nobody has >> tried to fix things. But that doesn't make it right. > > UNIX doesn't do this _at all_ well for "hosted OS's". > > The NetWare for UNIX product, which I worked on the attributed FS > (with resource forks and multiple namespaces) and the lock coherency > model on is one example. > > We had to add hooks into the fcntl() call in the FS to support > this. > > Something that might be interesting to look at in this regard is > the latest SAMBA code. > > The latest SAMBA code has an OS OPLOCK (Opportunity Locking) API > that it will utilize, if it is present (currently only on IRIX), > which deals with the lock coherency issues. > > Note that since SAMBA externalizes via SMB an interface that has > to implement NetBIOS calls, and those, in turn, externalize via > the DOS INT 2A/2C mechanisms into the file I/O INTs, that SAMBA > has to support mandatory locking. How does it do this under FreeBSD? Does it implement it internally? > In effect, it is an API which externalizes much of the same types > of operations that implement LEASE operations used by the current > FreeBSD NFS server implementation. > > I don't know if this would be quite sufficient (it's been a while > since I did a lease and order of operation audit on the VFS code, > and written up patches to support Jordan's class project of making > the NFS server locking work), but it should be a healthy start > down the right road, I think. > > Might even fix a couple of NFS bugs as a side benefit... > > Anyway, Sean's also right about needing mandatory file locks for > binary emulation of other platforms (some of which Sean coded for). > > Are file locks sufficient for Vinum, Greg? To repeat myself again: none of this is relevant to Vinum. The original problem I was looking out turned out not to require any other locking method than was already present in Vinum. > The current lock structures in FreeBSD are hung off the backing > inodes (of which specfs has none available that are not themselves > abstract), and the spec_advlock() function returns either EOPNOTSUPP > or EINVAL, based on the arguments its given. > > IMO, unless the lock list is hung off the vnode (I guess you > could hang the mandatory locks there, and leave the advisory > ones alone, but that's kind of a waste, especially if the locking > code can be reused), you aren't going to be able to do range > locks on your stripes. Where are advisory locks kept nowadays? I'll discuss this in a separate message. > Am I not understanding how Vinum's RAID 5 is implemented? Are > you using files for the stripes, or are you laying out the disk > as a true RAID 5 controller would lay it out? I'm laying out the disk in the same manner as a hardware RAID-5 controller would do it. Vinum's downward interface is to the disk driver, not the file system. I'll send a separate (hopefully last) message to try and sum up what I'm doing. 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
