Re: nfs stale filehandle issues with 2.6.10-rc1 in-kernel server
From: Jeff V. Merkey
Date: Wed Nov 03 2004 - 16:27:25 EST
Jeff V. Merkey wrote:
Trond Myklebust wrote:
Connect 2.4.18 and 2.6.9 with NFS 3 enabled. I am seeing problems
connecting and file size mismatches. I also see errors with zero
length files (host side) that get opened and populated with data
and the remote side is unable to read them -- keeps seeing them as
zero length.
That's entirely expected. NFS has always been forced to use a polling
model for attribute cache consistency. "man 5 nfs" and read all about
the "actimeo" mount options that control this behaviour.
Cheers,
Trond
Trond,
Thanks for the update. I noticed from another post on this thread
that the problems with
/etc/exports are being addressed. This was the other problem I was
seeing but it appears
to be getting fixed.
Jeff
Trond,
While you are running down this problem, I've located another odd
behavior you
may (or may not) chose to address. In my dsfs file system, I use sector
runs (large ones)
that can sometimes return odd sizes during running down a file for
reading.
i.e. I can return 4096,4096,4096,512,1024,4096,4096 block sizes on size
returns
from vfs_read() for 512 or 4096 block requests when the file is read
sequentially.
Under NTFS and other OS architectures, unless the final read attempt
returns 0 size
denoting end of file, this seems to be allowed. I noticed that all of
the linux code with
the exception of NFS also handles this situation quite nicely. NFS does
not. I have
noted that if NFS receives a read size smaller than the requested block,
it always assumes
end of file and terminates the next read. I hace modified dsfs to
always return
block sizes in a uniform manner so NFS will work properly, even though
the rest
of the Linux apps work just fine without assuming the end of file has
been reached.
I personally think this is a broken behavior, but perhaps it's in line
with some NFS
spec somewhere. I have coded around it, but thout I would mention it to
you.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/