> 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. Yes, the reader keeps issuing fixed size reads and eventually hits EOF. It then stat's the file over and over and when it sees more data available to read, it does the same thing. If I modify the reproducer to calculate the available bytes left in the file (as reported by the stat) and then make sure to never hit EOF, it is no longer reproducible. > 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. This is exactly what I believe is happening (as I kind of mentioned in earlier messages, although I haven't confirmed that its post-op attrs updating the size). Are you saying that even with locking you think this might still be possible? I had assumed that would synchronize the appender and the reader enough that it seemed unlikely, but I can try it. -- 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
