On Wed, Jan 09, 2008 at 05:06:33PM -0500, Rik van Riel wrote:
...
Just verified this at one customer site; they had a db that was last backed up
in 2003 :/
Thinking back on the atime discussion, I bet there would be some performance
problems in updating the ctime/mtime that often too :)
Reading the man page:
"The st_ctime and st_mtime fields of a file that is mapped with MAP_SHARED and
PROT_WRITE will be marked for update at some point in the interval between a
write reference to the mapped region and the next call to msync() with
MS_ASYNC or MS_SYNC for that portion of the file by any process. If there is no
such call, these fields may be marked for update at any time after a write
reference if the underlying file is modified as a result."
So, whenever someone writes in the region, this must cause us to update the
mtime/ctime no later than at the time of the next call to msync().
Could one do something like the lazy atime updates, coupled with a forced flush
at msync()?
The update must still happen, eventually, after a write to the mapped region
followed by an unmap/close even if no msync is ever called.
The msync only serves as a "no later than" deadline. The write to the region
triggers the need for the update.
At least this is how I read the standard - please feel free to correct me if I
am mistaken.
--
/ jakob
--
