Re: msync() behaviour broken for MS_ASYNC, revert patch?

[Linus Torvalds <torvalds@osdl.org>]

On Fri, 10 Feb 2006, Linus Torvalds wrote:
> 
> So WRITE_SYNC has clearly different behaviour. There's a good reason the 
> kernel internally has "start write" + "wait for write", and I'll repeat: 
> none of those reasons go away just because you move to user space.

Btw, just to clarify: there _are_ things that do change when you go from 
user space to kernel space. It's true that you lose some visibility, and 
it's also true that the kernel has more than just "start write" semantics. 

So the kernel actually has "start write, but don't wait for stuff that 
has IO already pending", and "start write, and if writeback was active on 
a re-dirtied page, wait for and re-start it". 

I don't know if user space wants quite -that- much choice. The "start 
write but ignore busy areas" doesn't actually make sense together with 
"wait for it", since you don't know what (if any) you're really waiting 
for.

So it's really three operations
 - try to start flushing, so that you'll have less work pending later
 - start flushing
 - wait for any pending flush

[ From a pure "correctness" angle, we could say that "start flushing" 
  is the same as "wait for pending" + "try to start". However, the "IO 
  should overlap as much as possible" argument says that that is the
  wrong thing to do, since we can start flushing non-pending IO before we 
  wait for the old pending one ]

Now, most user programs probably don't care one whit.

But I think Andrew's patch makes sense. It exposes the internal kernel 
working in a logical fasion for people who do care. Yes, it's 
Linux-specific, but hey, so is arguing about the exact semantics of 
MS_INVALIDATE (which is version-specific).

		Linus
-
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/