On Mon, 2008-09-22 at 18:05 +0200, Hans-Peter Jansen wrote: > For what is worth, this behavior is visible in bog standard writing/reading > files, (log files in my case, via the python logging package). It obviously > deviates from local filesystem behavior, and former state of the linux > nfs-client. Should we add patches to less, tail, and all other instruments > for watching/analysing log files (just to pick the tip of the ice rock) in > order to throw away runs of zeros, when reading from nfs mounted files? Or > should we ask their maintainers to add locking code for the nfs "read > files, which are written at the same time" case, just to work around > __some__ of the consequences of this bug? Imagine, how ugly this is going > to look! > > The whole issue is what I call a major regression, thus I strongly ask for a > reply from Trond on this matter. > > I even vote for sending a revert request for this hunk to the stable team, > where it is applicable, after Trond sorted it out (for 2.6.27?). > > Thanks, Aaron and Chuck for the detailed analysis - it demystified a wired > behavior, I observed here. When you're in a process to get real work done > in a fixed timeline, such things could make you mad.. Revert _what_ exactly? Please assume that I've been travelling for the past 5 weeks, and have only a sketchy idea of what has been going on. My understanding was that this is a consequence of unordered writes causing the file to be extended while some other task is reading. AFAICS, this sort of behaviour has _always_ been possible. I can't see how reverting anything will fix it. Trond -- 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
