Re: [PATCH] memory mapped files not updating timestamps

From: Peter Staubach
Date: Thu May 18 2006 - 18:14:34 EST

Peter Zijlstra wrote:

On Wed, 2006-05-17 at 20:24 +0100, Hugh Dickins wrote:

On Wed, 17 May 2006, Peter Staubach wrote:

The changes add support to detect when the modification time needs to be
updated by placing a hook in __set_pages_dirty_buffers and
__set_pages_dirty_nobuffers. One of these two routines will be invoked
when the dirty bit is detected in the pte. The hook sets a new bit in the
address_space mapping struct indicating that the file which is associated
with that part of the address space needs to have its modification and
change time attributes updated.

You're adding a little overhead to every set_page_dirty, when the vast
majority (ordinary writes) don't need it: their mctime update is already
well taken care of. (Or should we be deleting the code that does that?
I think I'd rather not dare.)

It would make the code more symetric.

It might, but I think that it might upset the guarantees that the system
already makes about timely mtime/ctime updates when a file is written to.
Those requirements are much tighter than the requirements for when those
time fields get updated for a modified mmap'd file. With the exception
of msync, really the only requirement for updating mtime and ctime for
an mmap'd file is that these time fields change, at some time.



I think you'd do better to target those places where set_page_dirty is
called on a mapped page - and do the file_update_time at that point -
or as near to that point as is sensible/permitted given the locking
(vma->vm_file gives you the file without needing inode_update_time).

Peter Zijlstra has patches relating to dirty mmaps in the -mm tree
at present: I need to take a look at those, and I'll see if it would
make sense to factor in this mctime issue on top of those - you may
want to do the same.

Look for the callsites of set_page_dirty_balance(), those two points are
where writable file pages are dirtied.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at