Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753984AbXLWLgH (ORCPT ); Sun, 23 Dec 2007 06:36:07 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751520AbXLWLf4 (ORCPT ); Sun, 23 Dec 2007 06:35:56 -0500 Received: from ns4.abinetworks.biz ([216.218.212.66]:33851 "EHLO ns4.abinetworks.biz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751309AbXLWLfy (ORCPT ); Sun, 23 Dec 2007 06:35:54 -0500 Message-ID: <476E47F5.4090807@abinetworks.biz> Date: Sun, 23 Dec 2007 12:35:17 +0100 From: Gianluca Alberici User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott CC: linux-kernel@vger.kernel.org Subject: Re: NFS EINVAL on open(... | O_TRUNC) on 2.6.23.9 References: <476CEC5E.9070002@abinetworks.biz> <838DE9A2-59B2-49FA-B3E8-89B26368B1CF@bluecamel.eml.cc> In-Reply-To: <838DE9A2-59B2-49FA-B3E8-89B26368B1CF@bluecamel.eml.cc> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4387 Lines: 140 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 #include #include #include #include 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/ -- 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/