Re: [NFS] blocks of zeros (NULLs) in NFS files in kernels >= 2.6.20

From: Chuck Lever
Date: Thu Sep 11 2008 - 13:50:22 EST

On Sep 11, 2008, at Sep 11, 2008, 1:19 PM, Aaron Straus wrote:

On Sep 11 12:55 PM, Chuck Lever wrote:
A more thorough review of the NFS write and flush logic that exists in
2.6.27 is needed if we choose to recognize this issue as a real


Sorry. I didn't mean we should revert the hunk. I was just trying to
help identify the cause of the new behavior.

I think this is a real problem albeit not a "serious" one. Network
file-systems usually try to avoid readers seeing blocks of zeros in
files, especially in this simple writer/reader case.

It wouldn't be bad if the file is written out of order occasionally, but
we see this constantly now.

We cannot write/read log files to NFS mounts reliably any more. That
seems like a valid use case which no longer works?

Were you able to modify your writer to do real fsync system calls? If so, did it help? That would be a useful data point.

NFS uses close-to-open cache coherency. Thus we expect the file to be consistent and up to date after it is opened by a client, but not necessarily if some other client writes to it after it was opened. We usually recommend file locking and direct I/O to minimize these problems.

Practically speaking this is often not enough for typical applications, so NFS client implementations go to further (non- standard) efforts to behave like a local file system. This is simply a question of whether we can address this while not creating performance or correctness issues for other common use cases.

Anyway, I'm not the NFS client maintainer, so this decision is not up to me.

Chuck Lever
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at