My company has budgeted $500 to this problem. To someone familiar
with Linux NFS locking code, this fix should take less than three hours.
I can supply access to two different IRIX machines and a number of Linux
machines for testing.
Any takers? Please? I needed this 3 months ago, but I'm about to
build a large web server pool using Linux. Irix is, unfortunately the file
server since it's the biggest piece of hardware we own.
Help?
On Mon, 9 Nov 1998, Olaf Kirch wrote:
> On Mon, 09 Nov 1998 11:28:33 EST, "Ben 'The Con Man' Kahn" wrote:
> > | Let me clarify some things. Nfs v2 does not support lockd/statd, i.e.
> > | file locking, as far as I know, only nfs v3 does.
>
> If this is what you get back from irix support I just hope you didn't
> have to pay for it.
>
> File locking has been around since NFSv2, even though the definitiion
> hasn't been made public for a while (it's online now through the opengroup
> web server, I think).
>
> > Well! I was sure surprised to hear that lockd doesn't work for
> > NFS v2! I haven't performed all the snooping yet because I have other
> > problems to deal with. It appears that the top 4 bits of the cookie can
> > be ignored. Here is the section from the man pages:
>
> Well, the limitation of lockd to 4byte cookies was just that it was
> so simple to do, and I'd never seen a NLM implementation that didn't
> do 4byte cookies. Technically, a cookie can be 1024 bytes long because
> it's a netobj :(
>
> The changes needed to be made are reasonably trivial, but not entirely.
> In lockd/xdr.h, you need to change nlm_args.cookie to look like this:
>
> struct nlm_args {
> ...
> struct nlm_cookie {
> unsigned char data[8]; /* normal NLM and irix */
> unsigned int len;
> } cookie;
> ...
> };
>
> Obviously the decode and encode routines need to be changed to handle
> up to 8byte cookies gracefully.
>
> The part where you've got to be careful is that for every NLM request,
> the corresponding response must have the same cookie. That's because
> Sun grafted their call/response NLM on their braindead ONC RPC
> implementation.
>
> So basically you've got to check the places where cookie gets copied
> to make sure we really copy the struct.
>
> > 32bitclients
> > Causes the server to mask off the high order 32 bits of
> > directory cookies in NFS version 3 directory operations.
>
> That's got absolutely nothing to do with NLM.
>
> > Although Alan Cox was looking at implimenting NFS v3. I haven't
> > heard any reports from it, but if that works even a little, our problems
> > are solved. :^)
>
> The NLM code was about the only part of the NFS code that I did not
> touch when doing the NFSv3 patches. Hence NLM will definitely not work
> with NFSv3 unless Alan adds the necessary patches.
>
> Olaf
> --
> Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
> okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
>
-Ben
------------------------------------ |\ _,,,--,,_ ,) ----------
Benjamin Kahn /,`.-'`' -, ;-;;'
(212) 924 - 2220 |,4- ) )-,_ ) /\
ben@cybersites.com --------------- '---''(_/--' (_/-' ---------------
Drawing on my fine command of language, I said nothing.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/