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 <[EMAIL PROTECTED]>, 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] for PGP public key
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
