Hi Chris, On Thu, 2015-02-26 at 10:45 -0500, Chris Perl wrote: > > Ok, I assume proper use of locking will address the situation and allow > > readers to get consistent data and not null bytes ? > > Yes, trond said this explicitly in one of his earlier replies. You may want to double check by modifying your reproducer to use locking. Just want to clarify that your example is of a writer appending to a file while a reader keeps trying to read upto the EOF. If so, what's happening is that the metadata (file size) becomes out of sync with actual file data requested from the NFS server due to post-op attr attached to the READ reply containing an updated (increased) file size. Then NULLs are introduced between the actual file data received and the new increased file size. This is then presented to user space. Before the synchronous READ path was removed from the NFS client code, this issue could be avoided by using the "sync" NFS mount option. cya, # -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
