On Sat, 11 Feb 2006, Nick Piggin wrote:
MS_INVALIDATE does that (in Linux),
I don't actually think it does.
In _current_ linux it does. In some other versions, it will have thrown the dirty data away. Also, it will make subsequent accesses much much more expensive - and it doesn't work on locked areas.
the spec is poorly worded but the
intention seems to be that it would push dirty state back into pagecache for
implementations such as ours.
As an application writer, you'd be absolutely crazy to depend on that.
linux@xxxxxxxxxxx has an application (database or logging I think), which
uses MS_SYNC to provide integrity guarantees, however it is possible to do
useful work between the last write to memory and the commit point. MS_ASYNC
is used to start the IO and pipeline work.
So you're saying that there is one application that knows it could use different semantics?
Now, please enumerate all the applications that use MS_ASYNC and prefer the current semantics.
When you know that, you have an argument.
In the meantime, you have an example of an application that wants _new_ semantics.
The current MS_ASYNC behaviour is the sane one. It's the one that doesn't
cause the harddisk to start ticking senselessly. It's the one that allows a
person on a laptop to say "don't write dirty data every 5 seconds - do it
just every hour".
Repeating something doesn't make it so.
In contrast, _your_ proposal is just inflexible and inconvenient.
Currently MS_ASYNC does the same as MS_INVALIDATE. But it used to start
IO (before 2.5.something), and apparently it does in Solaris as well.
Actually, it did _not_ use to start IO.
Then, somebody made it do so, and people eventually screamed, and it was reverted again.
Go check Linux-2.0 or something. You'll also see the "MS_INVALIDATE means throw the dirty bit away" behaviour.
The _sane_ semantics are that if you say "MS_INVALIDATE" the dirty bit is just thrown away. If you say "MS_INVALIDATE | MS_ASYNC", the dirty bit is saved in the page cache and then the page is unmapped. And MS_SYNC obviously does the same thing, except it also waits for it.
If somebody really really wants to "start flushing data now", then he can do
so, but that actually has absolutely zero to do with "msync()" any more. A
person who wants the flushing to start "now" might want to flush any random
I didn't quite understand what you're saying here.
I'm saying that "start flushing now" has _zero_ to do with an mmap.
It's a perfectly valid operation after a _write_ call too - even if you never mmaped the area at all.
So if somebody wants to start background IO, what has that got to do with msync()?