Hallvard Breien Furuseth wrote:
Should have changed the Subject: before. Anyway:
On 02/08/14 23:28, Howard Chu wrote:
Hallvard Breien Furuseth wrote:
On 02/08/14 22:31, Howard Chu wrote:
Note that this is invalidating an on-chip data cache which is typically only 32KB or so. It has nothing to do with flushing the buffer cache. ("flush" is a misnomer, but that's what the syscall is called.)
OK, but apparently it's still a cache which can include data from both metapages and datapages.
The thing is, it will only include *old* data from the meta pages or data pages. Because nothing that was updated by write() will be visible to the chip (thru the mmap) until the on-chip data cache is invalidated. And all of that old data will be self-consistent because until the metapage update is visible, nobody will go looking for any of the new datapages.
Why so? A busy machine throws data out of caches to make room for other data. Some other program could presumably cause it to throw out the old metapage version, exposing the new uncached version, while and old version of a datapage is still cached.
On a busy machine the old data page will be long gone from the cache. Keep in mind that an old data page being written by a current txn cannot have been referenced by any of the previous 2 txns.
Unless this is a fully associative LRU cache, so it always throws out the oldest pages first, and no mdb_copy process just read the cached datapage and thus refreshed it in the cache.
I remain suspicious of cacheflush(metapage and its datapages) in one call, instead of cacheflush(datapges) before write(metapage).