From owner-freebsd-hackers Fri Aug 27 19:55: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (Postfix) with ESMTP id 1BB8E14E0D for ; Fri, 27 Aug 1999 19:54:50 -0700 (PDT) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id MAA18143; Sat, 28 Aug 1999 12:22:13 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id MAA14420; Sat, 28 Aug 1999 12:22:07 +0930 (CST) Date: Sat, 28 Aug 1999 12:22:07 +0930 From: Greg Lehey To: Terry Lambert Cc: wes@softweyr.com, dcs@newsguy.com, chris@netmonger.net, hackers@FreeBSD.ORG Subject: Re: Mandatory locking? Message-ID: <19990828122207.E13904@freebie.lemis.com> References: <19990825155207.Q83273@freebie.lemis.com> <199908251825.LAA06751@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199908251825.LAA06751@usr08.primenet.com>; from Terry Lambert on Wed, Aug 25, 1999 at 06:25:31PM +0000 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 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