Re: [Cluster-devel] [PATCH v7 05/13] fat: make fat_update_time get its own timestamp

OGAWA Hirofumi <[email protected]> writes:

> Jeff Layton <[email protected]> writes:
>
>> I'm a little confused too. Why do you believe this will break
>> -o relatime handling? This patch changes two things:
>>
>> 1/ it has fat_update_time fetch its own timestamp (and ignore the "now"
>> parameter). This is in line with the changes in patch #3 of this series,
>> which explains the rationale for this in more detail.
>>
>> 2/ it changes fat_update_time to also update the i_version if any of
>> S_CTIME|S_MTIME|S_VERSION are set. relatime is all about the S_ATIME,
>> and it is specifically excluded from that set.
>>
>> The rationale for the second change is is also in patch #3, but
>> basically, we can't guarantee that current_time hasn't changed since we
>> last checked for inode_needs_update_time, so if any of
>> S_CTIME/S_MTIME/S_VERSION have changed, then we need to assume that any
>> of them may need to be changed and attempt to update all 3.
>>
>> That said, I think the logic in fat_update_time isn't quite right. I
>> think want something like this on top of this patch to ensure that the
>> S_CTIME and S_MTIME get updated, even if the flags only have S_VERSION
>> set.
>>
>> Thoughts?
>
> I'm not talking about "relatime" at all, I'm always talking about
> "lazytime".
>
> I_DIRTY_TIME delays to update on disk inode only if changed
> timestamp. But you changed it to I_DIRTY_SYNC, i.e. always update on
> disk inode by timestamp.

And if change like it, why doesn't same change goes to generic_update_time()?
It looks like generic_update_time() in this series doesn't work like you said.
-- 
OGAWA Hirofumi <[email protected]>