[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NFS locking... help!



In article <Pine.LNX.3.96.980304222301.12794A-100000@simula.efis.ucr.ac.cr>,
Marcelo E. Magallon <mmagallo@efis.ucr.ac.cr> wrote:
>On 4 Mar 1998, Miquel van Smoorenburg wrote:
>
>> >access("/home/mmagallo/GNUstep/Defaults/WindowMaker", R_OK) = 0
>> >stat("/home/mmagallo/GNUstep/Defaults/WindowMaker", {st_mode=0, st_size=0, ...}) = 0
>> >open("/home/mmagallo/GNUstep/Defaults/WindowMaker", O_RDONLY) = 4
>> >fcntl(4, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = -1 ENOLCK (No locks available)
>> >close(4)                                = 0
>> 
>> This just shows you that Linux 2.0.x has no support for NFS based
>> fcntl() file locking.
>
>I was about to write an addendum to my original post... it's kernel 2.1.86
>on both the server and the client. It only happens with that scenario. I
>ran across the hall, and on a 2.0.33 machine it loads ok (but there's no
>autofs there). Should I then seek an answer/fix at the kernel level? Why
>do other programs work ok? (Or at least seem to) It's only happening with
>WindowMaker.

Well, in that case I have to guess since I have no experience with that.
But I think that the 2.0.x kernel just does a local fcntl() lock (which
doesn't work over the network) and lets you be happy with that.

The 2.1.x kernel however, knows about network locking and tries to lock
over NFS since the client code supports that. That's how it should be,
ofcourse. But if you run the user-level nfsd (unfsd) on the server,
the lock is not rewarded. You should probably run the kernel nfsd on
the server and then it would work.

Mike.
-- 
 Miquel van Smoorenburg |  
    miquels@cistron.nl  |  Luck is when preparation meets opportunity


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: