From owner-freebsd-hackers Mon Aug 23 17: 3: 1 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 64B2F14F58; Mon, 23 Aug 1999 17:02:43 -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 JAA21420; Tue, 24 Aug 1999 09:31:30 +0930 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.3/8.9.0) id JAA87288; Tue, 24 Aug 1999 09:31:25 +0930 (CST) Date: Tue, 24 Aug 1999 09:31:25 +0930 From: Greg Lehey To: Garance A Drosihn Cc: Matthew Dillon , Poul-Henning Kamp , FreeBSD Hackers , FreeBSD Committers , Garrett Wollman , Mark Murray Subject: Re: Mandatory locking? Message-ID: <19990824093125.P83273@freebie.lemis.com> References: <199908232012.WAA78393@gratis.grondar.za> <19990823122719.G83273@freebie.lemis.com> <7071.935386172@critter.freebsd.dk> <19990823095310.A83273@freebie.lemis.com> <199908230031.RAA00909@apollo.backplane.com> <19990823100654.B83273@freebie.lemis.com> <199908230504.WAA01860@apollo.backplane.com> <19990823152849.H83273@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Garance A Drosihn on Mon, Aug 23, 1999 at 03:28:01PM -0400 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 Monday, 23 August 1999 at 15:28:01 -0400, Garance A Drosihn wrote: > At 3:28 PM +0930 8/23/99, Greg Lehey wrote: >> I'm a little surprised that there's any objection to the concept >> of mandatory locking. In transaction processing, locking is not >> optional, and if any process at all can access a file or set of... > > For what it's worth, I also like the idea of mandatory locking. > It's important to think through some of the implementation details, > but I would also like to see some way to specify mandatory locking > in at least some situations. > > I'm not particularly thrilled with the idea of keying it off chmod > bits, though. That seems like a recipe for disaster. Remember where that came from: System V. I don't like it either, but if we're going to do it, we should offer this method (maybe as an option) for compatibility reasons. > Anyway, I am also puzzled as to why there would be much objection to > the option of mandatory locking. My initial systems-programming > experience was on a mainframe OS where mandatory locking was the > NORM, and you had to go out of your way to avoid locking. It seemed > to work quite well in my experience. Ditto in all points. I think that the people who are objecting are seeing potential rather than real problems. Obviously you don't apply mandatory locking to every file, but there are many cases where it makes sense. On Monday, 23 August 1999 at 17:47:46 -0400, Garance A Drosihn wrote: > At 10:12 PM +0200 8/23/99, Mark Murray wrote: >> Folk are all skirting around a very convenient (and necessary) >> loophole; in cases where there _is_ mandatory locking, there >> is always some meta-user which is allowed to violate this. > > If we include non-unix systems in the discussion, this isn't > always true. In the mainframe OS that I used to work on, there was > no meta-user who could just ignore locks set by other processes. > The super-user could find which process had a file locked, and > kill that process (thus removing the lock). Or the super-user > could run a program which modified the in-core locking table > so the file did not appear to be locked. Exactly. The reason why mandatory locking isn't a problem is because it's possible to kill processes holding the locks. It should be possible to find out who these processes are. > However, ordinary programs run by that super user did not have > any magic power to ignore mandatory locks set by some other > process. > > It is true that nobody is running that mainframe OS anymore... :-) They're running similar OSs. Tandem's NSK, for example, has always had mandatory locking. > I'm just saying we COULD (and maybe "should"?) implement this > such that even root has to honor mandatory locks. Root (or some > thing) would have a way to get around or cancel the mandatory > lock, but "standard" programs run by root should not bypass the > mandatory locking. (IMO) I don't think that it should be necessary for root to have this override. The tendency in the last few years has been to lessen root's authority, not increase it. And remember, just because people on this forum haven't had much experience with mandatory locking doesn't mean that others don't: it's been in use for years, and people *don't* have (many) problems with deadlocks. The real issue here is that (mandatory) locking is standard on just about every operating system nowadays. I'd guess that even Microsoft has it. The lack of support on FreeBSD doesn't improve the system. I've done some searching on the web, and came up with a lot of stuff. http://homer.njit.edu:8000/cis332/flock.html and http://miller.cs.wm.edu/lxr3.linux/http/source/Documentation/mandatory.txt seem to be the most interesting. 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