Re: [PATCH] memory mapped files not updating timestamps

[Peter Staubach <staubach@redhat.com>]

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.

    Thanx...

       ps

>>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.
>
>PeterZ
>
>  
>