Messages in this thread | | | Subject | Re: msync() behaviour broken for MS_ASYNC, revert patch? | From | Trond Myklebust <> | Date | Fri, 10 Feb 2006 18:02:53 -0500 |
| |
On Fri, 2006-02-10 at 14:46 -0800, Linus Torvalds wrote: > > On Fri, 10 Feb 2006, Trond Myklebust wrote: > > > > The Single Unix Spec appears to have a very different interpretation. > > Hmm. Very different wording, but same meaning, I think. > > > When MS_INVALIDATE is specified, msync() shall invalidate all > > cached copies of mapped data that are inconsistent with the > > permanent storage locations such that subsequent references > > shall obtain data that was consistent with the permanent storage > > locations sometime between the call to msync() and the first > > subsequent memory reference to the data. > > Again, this says that the _mapping_ is invalidated, and should match > persistent storage. > > Any dirty bits in the mapping (ie anything that hasn't been msync'ed) > should be made persistent with permanent storage. Again, that is entirely > consistent with just throwing the mmap'ed page away (dirty state and all) > in a non-coherent environment. > > I don't think we really have any modern Unixes with non-coherent mmap's > (although HP-UX used to be that way for a _loong_ time). But in the > timeframe that was written, it was probably still an issue. > > Now, in a _coherent_ environment (like Linux) it should probably be a > no-op, since the mapping is always consistent with storage (where > "storage" doesn't actyally mean "disk", but the virtual file underneath > the mapping).
Hmmm.... When talking about syncing to _permanent_ storage one usually is talking about what is actually on the disk. In any case, we do have non-coherent mmapped environments in Linux (need I mention NFS, CIFS, ... ;-)?).
IIRC msync(MS_INVALIDATE) on Solaris was actually often used by some applications to resync the client page cache to the server when using odd locking schemes, so I believe this interpretation is a valid one.
Cheers, Trond
- 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/
| |