Date: Sun, 29 Aug 1999 10:01:49 +0930 From: Greg Lehey <grog@lemis.com> To: Peter Dufault <dufault@hda.com> Cc: hackers@FreeBSD.org, commit@freebie.lemis.com Subject: Re: locking revisited Message-ID: <19990829100149.M13904@freebie.lemis.com> In-Reply-To: <199908281916.PAA09116@hda.hda.com>; from Peter Dufault on Sat, Aug 28, 1999 at 03:16:28PM -0400 References: <19990828125241.G13904@freebie.lemis.com> <199908281916.PAA09116@hda.hda.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, 28 August 1999 at 15:16:28 -0400, Peter Dufault wrote: >> As a result, I argue that we should implement locking. The questions >> are: how? I'd suggest three methods which can be individually enabled >> via sysctls: >> >> - System V style. We need this for compatibility with System V. The >> choice of mandatory or advisory locking depends on the file >> permissions. >> >> - Only mandatory locking. fcntl works as before, but locks are >> always mandatory, not advisory. I'm sure that this won't be >> popular, at least initially, but if you don't like it, you don't >> have to use it.y >> >> - Via separate calls to fcntl. fcntl currently has the following >> command values: >> >> #define F_DUPFD 0 /* duplicate file descriptor */ >> #define F_GETFD 1 /* get file descriptor flags */ >> #define F_SETFD 2 /* set file descriptor flags */ >> #define F_GETFL 3 /* get file status flags */ >> #define F_SETFL 4 /* set file status flags */ >> #define F_GETOWN 5 /* get SIGIO/SIGURG proc/pgrp */ >> #define F_SETOWN 6 /* set SIGIO/SIGURG proc/pgrp */ >> #define F_GETLK 7 /* get record locking information */ >> #define F_SETLK 8 /* set record locking information */ >> #define F_SETLKW 9 /* F_SETLK; wait if blocked */ >> >> We could add a F_SETMANDLOCK or some such. >> >> Any thoughts? > > (I'm following up only on -hackers because I personally hate discussions > in -commit.) I'm copying -commit because that's where we're supposed to discuss these things. I made the mistake of excluding them once before, and the results were painful. > 1. Isn't vinum a device? Yes. > Isn't this file-level locking irrelevant? To Vinum, yes. > Shouldn't all locking for maintenance be done at the device level? Maybe. Depends on what kind of maintenance you're doing. What happens if you want to dd one plex to another? You've missed another message of mine, where I said that this issue has no relevance to Vinum. > 2. I'll bet there are some standards, at least in development. Have you > done a few searches? Sure. The important one was in the attachment: System V has a standard. > I have other opinions, some that I hold strongly, but since they > have to do with lack of definition of boundary conditions then I > won't bring them up until (2.) is answered. Go for it. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990829100149.M13904>