LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Gianluca Alberici <gianluca@abinetworks.biz>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Scott <linux-kernel@bluecamel.eml.cc>,
	linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: NFS EINVAL on open(... | O_TRUNC) on 2.6.23.9
Date: Wed, 26 Dec 2007 12:14:42 +0100	[thread overview]
Message-ID: <477237A2.3040907@abinetworks.biz> (raw)
In-Reply-To: <20071225140431.9264970a.akpm@linux-foundation.org>

Hello all,

I've seen that Trond and the other guys at Netapp are working hard on 
the NFS support and there are dozens of patches in latest
2.6.24rcX s kernels regarding both RPC and NFS.
I can only hope, as Andrew Morton said, that the policy of new NFS impl 
was 'dont break'.
In the end those buggy, dreaded, old fashioned NFSs have done their job 
excellently for over 15 years and will be around for
another 5 IMHO.

Anyways, id really would be so thankful if somebody from the NFS team 
was givin us a clue about the whole thing.

TIA

Gianluca

Andrew Morton wrote:

>On Sun, 23 Dec 2007 12:35:17 +0100 Gianluca Alberici <gianluca@abinetworks.biz> wrote:
>
>  
>
>>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 ?
>>
>>    
>>
>
>I'm not sure what the NFS client's policy is regarding support for
>userspace servers.  But I'd certainly hope that it is "don't break them".
>
>Which would make this an NFS client regression.
>--
>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/
>  
>


  reply	other threads:[~2007-12-26 11:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-22 10:52 Gianluca Alberici
2007-12-23  7:17 ` Scott
2007-12-23 11:35   ` Gianluca Alberici
2007-12-25 22:04     ` Andrew Morton
2007-12-26 11:14       ` Gianluca Alberici [this message]
2007-12-26 14:24       ` Chuck Lever
2008-01-19 11:29         ` Gianluca Alberici
2008-01-19 12:35         ` Gianluca Alberici
     [not found]           ` <5FD6714F-EF9A-4F07-B2B6-D6F6CC911936@oracle.com>
     [not found]             ` <479C744A.6020207@abinetworks.biz>
     [not found]               ` <12964A18-350B-443F-B15A-D78B3723C89A@oracle.com>
     [not found]                 ` <479F2463.2040704@abinetworks.biz>
     [not found]                   ` <4AAA3DAF-898C-4ED5-BD07-4FD2B5CEEF16@oracle.com>
     [not found]                     ` <Pine.LNX.4.64.0801291851110.4820@maggie.lkpg.cendio.se>
     [not found]                       ` <7EE4B02B-3359-41C0-BFED-0947DF9F5F5A@oracle.com>
     [not found]                         ` <479F8377.6090704@abinetworks.biz>
     [not found]                           ` <1201638661.7969.7.camel@heimdal.trondhjem.org>
     [not found]                             ` <F7BFE847-A3C3-44E5-A238-5C69ED3EE1C4@oracle.com>
     [not found]                               ` <47A0704D.7080808@abinetworks.biz>
     [not found]                                 ` <AB6DF303-5C5B-453C-9992-DAF826FF02CE@oracle.com>
2008-02-06 18:25                                   ` Gianluca Alberici
2008-02-06 19:47                                     ` Chuck Lever
2008-02-06 21:55                                       ` Gianluca Alberici
2008-02-06 22:16                                         ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=477237A2.3040907@abinetworks.biz \
    --to=gianluca@abinetworks.biz \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@bluecamel.eml.cc \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --subject='Re: NFS EINVAL on open(... | O_TRUNC) on 2.6.23.9' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).