Hi, On Sep 22 12:35 PM, Trond Myklebust wrote: > Revert _what_ exactly? Yep. I narrowed the problem down to an offending hunk in a particular patch. Removing that hunk did eliminate the problem. However, reverting that hunk is likely wrong and the code has changed _a lot_ since that commit. > My understanding was that this is a consequence of unordered writes > causing the file to be extended while some other task is reading. Yes. I added some debugging statements to look at the writeout path. I think the following happens: - page 0 gets partially written to by app - VM writes out partial dirty page 0 - page 0 gets fully written by app - page 1 gets partially written by app - VM writes out dirty page 1 At this point there is a hole in the file. The tail end of page 0 is still not written to server. - VM writes out dirty page 0 ... > AFAICS, this sort of behaviour has _always_ been possible. I can't see > how reverting anything will fix it. Here is the crux. It was possible previously but unlikely e.g. our app never saw this behavior. The new writeout semantics causes visible holes in files often. Anyway, I agree the new writeout semantics are allowed and possibly saner than the previous writeout path. The problem is that it is __annoying__ for this use case (log files). I'm not sure if there is an easy solution. We want the VM to writeout the address space in order. Maybe we can start the scan for dirty pages at the last page we wrote out i.e. page 0 in the example above? =a= -- =================== Aaron Straus aaron@xxxxxxxxxxxxx -- 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
