Remove issue with Patch Kernel 2.6.25-rc9-CITI_NFS4_ALL-1
Christopher T Vogan
cvogan at us.ibm.com
Tue Jul 22 16:42:05 EDT 2008
Trond,
I think I am seeing the remove issue again on a system with a patched CITI
kernel 2.6.25-rc9-CITI_NFS4_ALL-1.
I have a C program that issues:
Open
Stat
Close
Remove
The remove never gets sent, instead the client wants to rename the file
to .nfs000000009b331bb0000000b2 . This fails for us since we can not have
a name greater then 8 chars, including the leading period on zOS.
I am trying to understand why the linux client want to rename the file in
the first place.
See the attached network trace.
Basicly this is whats going on.
Frame 139 Close Call
Frame 140 Lookup .nfs000000007b9ee00d000000b5 <-- why did you not wait
for the close reply?
Frame 141 TCP packet
Frame 142 Lookup Reply NFS4ERR_NAMETOOLONG <-- we can except this, its
not an error on the server.
Frame 143 Close reply NFS_OK
This test showed that the Linux Client did not wait for the server to reply
to the close. This is the same error I had reported before. See notes
below.
Linux Client trace:
Jul 22 13:24:15 reddy kernel: NFS: commit (0:17/2074009613 4096 at 40960) OK
Jul 22 13:24:15 reddy kernel: NFS: commit (0:17/2074009613 4096 at 45056) OK
Jul 22 13:24:15 reddy kernel: NFS: permission(0:17/480693409), mask=0x1,
res=0
Jul 22 13:24:15 reddy kernel: encode_compound: tag=
Jul 22 13:24:15 reddy kernel: NFS: permission(0:17/480693409), mask=0x1,
res=0
Jul 22 13:24:15 reddy kernel: NFS: nfs_lookup_revalidate
(/LEGACY.FILEA1,binary,recfm(vb)) is valid
Jul 22 13:24:15 reddy kernel: NFS: permission(0:17/480693409), mask=0x3,
res=0,
Jul 22 13:24:15 reddy kernel: NFS: unlink(0:17/480693409,
LEGACY.FILEA1,binary,recfm(vb))
Jul 22 13:24:15 reddy kernel: NFS: silly-rename(/LEGACY.FILEA1,binary,recfm
(vb), ct=2)
Jul 22 13:24:15 reddy kernel: NFS: trying to rename
LEGACY.FILEA1,binary,recfm(vb) to .nfs000000007b9ee00d000000b5
Jul 22 13:24:15 reddy kernel: NFS: permission(0:17/480693409), mask=0x1,
res=0
Jul 22 13:24:15 reddy kernel: NFS: atomic_lookup
(0:17/480693409), .nfs000000007b9ee00d000000b5
Jul 22 13:24:15 reddy kernel: NFS: lookup(/.nfs000000007b9ee00d000000b5)
Jul 22 13:24:15 reddy kernel: NFS call lookup .nfs000000007b9ee00d000000b5
Jul 22 13:24:15 reddy kernel: NFS call
lookupfh .nfs000000007b9ee00d000000b5
Jul 22 13:24:15 reddy kernel: encode_compound: tag=
Jul 22 13:24:15 reddy kernel: NFS reply lookupfh: -36
Jul 22 13:24:15 reddy kernel: NFS reply lookup: -36
Jul 22 13:24:15 reddy kernel: NFS: dentry_delete
(/.nfs000000007b9ee00d000000b5, 10)
(See attached file: remove.txt)(See attached file: remove.pcap)
Christopher Vogan
Dept. W98 NFS Development & Test
From: Christopher T Vogan/San Jose/IBM
To: Christopher T Vogan/San Jose/IBM at IBMUS
Cc: nfsv4 at linux-nfs.org, Trond Myklebust <trond.myklebust at fys.uio.no>
Date: 07/22/2008 02:52 PM
Subject: Re: Remove issue with Patch Kernel 2.6.25-rc9-CITI_NFS4_ALL-1
From: Christopher T Vogan/San Jose/IBM
To: Trond Myklebust <trond.myklebust at fys.uio.no>
Cc: nfsv4 at linux-nfs.org
Date: 03/20/2008 04:53 PM
Subject: Re: Remove issue with Vanilla install of Fedora 7
That looks like the issue I am seeing.
I have a question regarding this. I have system that is running lower
levels of Citi patched kernels i.e.(2.6.21) and It does not have this
problem.
But I have a redhat el5 system with a 2.6.18-53.1.6.el5 and it has the same
issue I reported below.
How come the Citi Patched systems do not have this problem? It might have
been cought sooner by us. As We will catch our of order close
rename/remove's from Linux as file names > 8 chars are invalid on IBM
manframes.
Christopher Vogan
Dept. W98 NFS Development & Test
Trond Myklebust
<trond.myklebust@
fys.uio.no> To
Christopher T Vogan/San
03/20/2008 04:23 Jose/IBM at IBMUS
PM cc
nfsv4 at linux-nfs.org
Subject
Re: Remove issue with Vanilla
install of Fedora 7
On Thu, 2008-03-20 at 09:29 -0600, Christopher T Vogan wrote:
> I have been testing vanilla installs of Suse, Redhat and Fedora with
> NFSv4.
> I have stumbled upon a issue that I can not explain.
> The issue is the Linux client (Fedora 7) sends a CLOSE call. Before
> the server replies to the CLOSE the Linux client issue a rename. I
> wanted a remove I know why the linux client did that, it thinks the
> file is still open. What I do not understand is why did the Linux
> client not wait for the CLOSE call to reply before trying to remove
> the file?
> In this case the remove failed because of an invalid file name
> NAMETOOLONG which is expected in this case..
>
> This issue does not happen on a system that has CITI kernel with
> patches and Userland utilities CITI provides. I am wondering if I have
> a configuration issue. I never saw this problem with prior or newer
> kernels. Is this something that the patched kernels resolve?
>
> In the network trace (the part of interest):
>
> CALL CLOSE
> CALL LOOKUP <- rename to replace remove
> REPLY CLOSE
> REPLY LOOKUP
>
>
> The test program does 4 things in this order to recreate this issue.
> OPEN fd
> STAT fd
> CLOSE fd
> REMOVE fd
>
>
> I gathered NFS client and RPC debug info and a network trace. I am
> also including a testcase to reproduce the problem.
> (See attached file: openclose.pcap)(See attached file:
> openclose.txt)(See attached file: openclose.c)
>
> Christopher Vogan
> Dept. W98 NFS Development & Test
That looks very much like the bug described in
http://bugzilla.linux-nfs.org/show_bug.cgi?id=150
The fix was merged into 2.6.24-rc1. You can find it documented at
http://git.linux-nfs.org/?p=trondmy/nfs-2.6.git&a=commitdiff&h=a49c3c7736a2e77931dabc5bc4a83fb4b2da013e
Cheers
Trond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://linux-nfs.org/pipermail/nfsv4/attachments/20080722/16da8e61/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://linux-nfs.org/pipermail/nfsv4/attachments/20080722/16da8e61/attachment.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://linux-nfs.org/pipermail/nfsv4/attachments/20080722/16da8e61/attachment-0001.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic00977.gif
Type: image/gif
Size: 1255 bytes
Desc: not available
Url : http://linux-nfs.org/pipermail/nfsv4/attachments/20080722/16da8e61/attachment-0002.gif
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remove.txt
Type: application/octet-stream
Size: 706923 bytes
Desc: not available
Url : http://linux-nfs.org/pipermail/nfsv4/attachments/20080722/16da8e61/attachment.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remove.pcap
Type: application/octet-stream
Size: 76558 bytes
Desc: not available
Url : http://linux-nfs.org/pipermail/nfsv4/attachments/20080722/16da8e61/attachment-0001.obj
More information about the NFSv4
mailing list