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.g83...@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 <g...@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 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
