Stephen C. Tweedie wrote:> > If so, what was the change?> > 2.4.9 behaved like current 2.6 --- on MS_ASYNC, it did a> set_page_dirty() which means the page will get picked up by the next> 5-second bdflush pass. But later 2.4 kernels were changed so that they> started MS_ASYNC IO immediately with filemap_fdatasync() (which is> asynchronous regarding the new IO, but which blocks synchronously if> there is already old IO in flight on the page.)> > That was reverted back to the earlier, 2.4.9 behaviour in the 2.5> series.

It was 2.5.68.

Thanks, that's very helpful.

msync(0) has always had behaviour consistent with the <=2.4.9 and>=2.5.68 MS_ASYNC behaviour, is that right?

If so, programs may as well "#define MS_ASYNC 0" on Linux, to get welldefined and consistent behaviour. It would be nice to change thedefinition in libc to zero, but I don't think it's possible becausemsync(MS_SYNC|MS_ASYNC) needs to fail.