Date: Mon, 23 Aug 1999 15:28:49 +0930 From: Greg Lehey <grog@lemis.com> To: Matthew Dillon <dillon@apollo.backplane.com>, Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: FreeBSD Hackers <hackers@FreeBSD.ORG>, FreeBSD Committers <cvs-committers@FreeBSD.ORG>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Subject: Re: Mandatory locking? Message-ID: <19990823152849.H83273@freebie.lemis.com> In-Reply-To: <199908230504.WAA01860@apollo.backplane.com>; from Matthew Dillon on Sun, Aug 22, 1999 at 10:04:38PM -0700 References: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, 22 August 1999 at 22:04:38 -0700, Matthew Dillon wrote: > >> Somehow you need to get a lock. >> >>> You mean have one program make a fcntl call that causes other >>> programs to return an error or block if they try to open that >>> file while the first program holds an open descriptor? >> >> Correct. I suppose it's worth discussing what the default should be. >> Should they get EAGAIN or block? Obviously you'd want a way of >> specifying which, but there would have to be a default for >> non-lock-aware programs. I think I'd go for blocking; it's less error >> prone. > > I dunno, it sounds pretty icky to me. I would redesign whatever you > are doing that requires mandatory locks to use advisory locks > instead. > > It can be as simple as a wrapper around whatever program your users are > running that is causing whatever the problem is. I'm accessing a file that any program might want to open. Redesigning everything isn't an option. On Monday, 23 August 1999 at 7:29:32 +0200, Poul-Henning Kamp wrote: > In message <19990823122719.G83273@freebie.lemis.com>, Greg Lehey writes: >> On Sunday, 22 August 1999 at 22:52:33 -0400, Garrett Wollman wrote: >>> <<On Mon, 23 Aug 1999 12:09:50 +0930, Greg Lehey <grog@lemis.com> said: >>> >>>> That's a strange thing to say. Should we do away with locks in the >>>> kernel too? >>> >>> Of course not. Locks in the kernel are actually necessary. >> >> So what's unspeakably evil about ensuring that user processes don't >> tread on each other's feet? In my specific case, I need to make a >> Vinum volume inaccessible while rebuilding the parity stripes. How >> would you ensure that? A user process is doing the rebuilding. > > Then you give that user-process a magic ioctl to do it with. That sounds like a kludge to me. > Why should it be made unavailable ? So that certain multiple accesses can be done atomically. > I thought the idea of RAID-5 was that this wasn't needed ? No, the idea of RAID-5 is that you can tolerate failures. 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 files without locking, you can't guarantee the database integrity. Other OSs have used mandatory locking for decades, and System V has it too. So far I haven't seen any arguments, let alone valid ones, against having it in FreeBSD. 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?19990823152849.H83273>