With much digress and some curse words uttered, i just had the same
issue happen on a Ubuntu 2.6.32 kernel. So I'm back to square one, and
assuming it's server side.
Thanks for your suggestions and I guess we can close this one out until
I once again can determine that it's client side, which I don't think I can.
Thanks,
Jason
On 10-10-11 06:48 PM, Ben Hutchings wrote:
On Mon, 2010-10-11 at 14:50 -0400, Jason Kendall wrote:
On 10-10-11 01:19 PM, Ben Hutchings wrote:
On Mon, Oct 11, 2010 at 12:49:33PM -0400, Jason Kendall wrote:
Package: linux-2.6
Severity: important
Tags: upstream
Which version?
uname was further in the report (i used reportbug so It should have been
there. At the time of report it was 2.6.32-5-686-bigmem.
That's not the package version but the ABI version.
2. Duplicate filenames are given when doing an "ls"
3. Trigger happens when a rename (mv) happens on a directory with a large
number of files.
4. Does not matter which machine does the rename/mv (Any box connected to the
NFS) the duplicate filenames still show up under DomU
5. Does not appear to happen to directories with a limited number of files. I have
one directory with> 9k files which this does happen on (mail directory)
This is probably an effect of the NFS block size - any directory smaller
than a single block is likely to be readable atomically.
Upped the block size and same issue.
(rw,rsize=32768,wsize=32768,hard,fg,nolock,nfsvers=3,tcp,actimeo=0,addr=10.0.0.7).
Prior, it was just mounted with defaults
I think that's the default block size now.
[...]
Looking at a pcap, NFSClient doesn't appear to be asking the server for
the filenames, however, there is a large number of "ACCESS" and
"GETATTR" requests. Most are returned as "Directory", a few are
returned as "Regular File". Of the Regular files, there is 3 returned,
all the same file handle, and appear to be the same stats. There is
matching GETATTR calls prior to each Regular File Reply, and a number of
requests in between each one.
touching the file to update the mtime does not resolve the issue.
[...]
What about touching the directory?
Ben.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cb3a792....@gmail.com
