Hi,

On Sep 22 12:35 PM, Trond Myklebust wrote:
quoted text
> 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.

quoted text
> 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
  ...

quoted text
> 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@merfinllc.com
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/