lkml.org 
[lkml]   [2007]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] update ctime and mtime for mmaped write
Miklos Szeredi wrote:
>>>>> Inspired by Peter Staubach's patch and the resulting comments.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> An updated version of the original patch was submitted to LKML
>>>> yesterday... :-)
>>>>
>>>>
>>> Strange coincidence :)
>>>
>>>
>>>
>>>>> file = vma->vm_file;
>>>>> start = vma->vm_end;
>>>>> + mapping_update_time(file);
>>>>> if ((flags & MS_SYNC) && file &&
>>>>> (vma->vm_flags & VM_SHARED)) {
>>>>> get_file(file);
>>>>>
>>>>>
>>>>>
>>>> It seems to me that this might lead to file times being updated for
>>>> non-MAP_SHARED mappings.
>>>>
>>>>
>>> In theory no, because the COW-ed pages become anonymous and are not
>>> part of the original mapping any more.
>>>
>>>
>>>
>> I must profess to having a incomplete understanding of all of this
>> support, but then why would it be necessary to test VM_SHARED at
>> this point in msync()?
>>
>
> That's basically just an optimization. If it wasn't there, then data
> from a another (shared) mapping could be written back, which is not
> wrong, but not required either.
>
>
>> I ran into problems early on with file times being updated incorrectly
>> so I am a little sensitive this aspect.
>>
>>
>>>>> +int set_page_dirty_mapping(struct page *page);
>>>>>
>>>>>
>>>>>
>>>> This aspect of the design seems intrusive to me. I didn't see a strong
>>>> reason to introduce new versions of many of the routines just to handle
>>>> these semantics. What motivated this part of your design? Why the new
>>>> _mapping versions of routines?
>>>>
>>>>
>>> Because there's no way to know inside the set_page_dirty() functions
>>> if the dirtying comes from a memory mapping or from a modification
>>> through a normal write(). And they have different semantics, for
>>> write() the modification times are updated immediately.
>>>
>> Perhaps I didn't understand what page_mapped() does, but it does seem to
>> have the right semantics as far as I could see.
>>
>
> The problems will start, when you have a file that is both mapped and
> modified with write(). Then the dirying from the write() will set the
> flag, and that will have undesirable consequences.

I don't think that I quite follow the logic. The dirtying from write()
will set the flag, but then the mtime will get updated and the flag will
be cleared by the hook in file_update_time(). Right?

Thanx...

ps
-
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/

\
 
 \ /
  Last update: 2007-02-22 18:57    [W:0.090 / U:0.900 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site