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/