Re: NFS EINVAL on open(... | O_TRUNC) on 2.6.23.9

[Gianluca Alberici <gianluca@abinetworks.biz>]

Hello,

I can do better. I have investigated a bit the problem:

1) The problem arises only with the userspace nfsd (Universal nfsd 2.2). 
I have realized that the latest patches introduced in 2.6.22 have 
changed a lot of things into NFS.

2) The following code has been debugged with sunrpc.rpc_debug and 
sunrpc.nfs_debug

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>
#include <stdio.h>

int main(int argc, char *argv[]) {
        int fp;
        if ((fp=open("/mnt/tmp/test",O_WRONLY | O_CREAT | O_TRUNC, S_IRWXU )) == -1) printf("ERR: %d\n",errno);
        else {
                write(fp, argv[1], strlen(argv[1]));
                printf("OK\n");
                close(fp);
        };
}


2b) The output

[...]

<8>NFS call  setattr
<8>RPC:       new task initialized, procpid 18656
<8>RPC:       allocated task f7bec500
<8>RPC:     0 looking up UNIX cred
<8>RPC:   740 __rpc_execute flags=0x480
<8>RPC:   740 call_start nfs2 proc 2 (sync)
<8>RPC:   740 call_reserve (status 0)
<8>RPC:   740 reserved req f1416000 xid 643f3c42
<8>RPC:   740 call_reserveresult (status 0)
<8>RPC:   740 call_allocate (status 0)
<8>RPC:   740 allocated buffer of size 528 at e627b800
<8>RPC:   740 call_bind (status 0)
<8>RPC:   740 call_connect xprt f70d4000 is connected
<8>RPC:   740 call_transmit (status 0)
<8>RPC:   740 xprt_prepare_transmit
<8>RPC:   740 xprt_cwnd_limited cong = 0 cwnd = 512
<8>RPC:   740 call_encode (status 0)
<8>RPC:   740 marshaling UNIX cred f4efcb40
<8>RPC:   740 using AUTH_UNIX cred f4efcb40 to wrap rpc data
<8>RPC:   740 xprt_transmit(148)
<8>RPC:       xs_udp_data_ready...
<8>RPC:       cong 256, cwnd was 512, now 512
<8>RPC:   740 xid 643f3c42 complete (28 bytes received)
<8>RPC:       xs_udp_send_request(148) = 148
<8>RPC:   740 xmit complete
<8>RPC:       wake_up_next(f70d4114 "xprt_resend")
<8>RPC:       wake_up_next(f70d40e4 "xprt_sending")
<8>RPC:   740 call_status (status 28)
<8>RPC:   740 call_decode (status 28)
<8>RPC:   740 validating UNIX cred f4efcb40
<8>RPC:   740 using AUTH_UNIX cred f4efcb40 to unwrap rpc data
<8>RPC:   740 call_decode result -22
<8>RPC:   740 return 0, status -22
<8>RPC:   740 release task
<8>RPC:       freeing buffer of size 528 at e627b800
<8>RPC:   740 release request f1416000
<8>RPC:       wake_up_next(f70d4174 "xprt_backlog")
<8>RPC:   740 releasing UNIX cred f4efcb40
<8>RPC:       rpc_release_client(f6f1f880)
<8>NFS reply setattr: -22

[...]

3) It turns out the following:

- setattr returns EINVAL due to...
- RPC call_decode returns status 22

4) In conclusion in my understanding:

- At present linux nfs filesystem support is not anymore compatible with 
old userspace servers like universal nfsd and crypto filesystems as cfsd 
(which is an nfs server pretty old fashioned).
- This problem makes UNFSD and CFSD unusable on 2.6.22 and up (this 
doesnt sound good to me)

The question are:

- Is this wanted or is a bug ?
- Can this be solved with some backwards compat stuff into the kernel or 
all the old packages as UNFSD have to be
bugfixed/upgraded
- I have found other strange behaviors of the new NFS filesystem support 
that i am investigating. All are bound to the user of
old userspace servers onto the new NFS (since 2.6.22). What to do ?

Thanks

Gianluca




Scott wrote:

>
> On Dec 22, 2007, at 5:52 AM, Gianluca Alberici wrote:
>
>> I've run into this problem 2.6.23.9. The open syscall will return
>> "Invalid argument" when O_TRUNC is set on existing files.
>>
>> The same file can be opened for append or removed.
>>
>> The evidence is for example:
>>
>> mars:~# mount localhost:/opt/nfs/ /mnt/tmp
>> mars:~# echo "Hello" > /mnt/tmp/test-file
>> mars:~# echo "Hello" > /mnt/tmp/test-file
>> bash: /mnt/tmp/test-file: Invalid argument
>
>
> Can you show an strace of this please? Also, might suggest "rpcdebug - 
> m nfsd -s all"
>
> -- 
> Scott --
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/