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

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

 

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux