lkml.org 
[lkml]   [2011]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Update atime from future.
On 01/03/2011 06:27 PM, Steven Whitehouse wrote:
> Hi,
>
> On Wed, 2010-12-29 at 21:58 +0800, yangsheng wrote:
>
>> Signed-off-by: sickamd@gmail.com
>> ---
>> fs/inode.c | 8 +++++++-
>> 1 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/inode.c b/fs/inode.c
>> index da85e56..6c8effd 100644
>> --- a/fs/inode.c
>> +++ b/fs/inode.c
>> @@ -1469,7 +1469,13 @@ static int relatime_need_update(struct vfsmount *mnt, struct inode *inode,
>> return 1;
>>
>> /*
>> - * Is the previous atime value older than a day? If yes,
>> + * Is the previous atime value in future? If yes,
>> + * update atime:
>> + */
>> + if ((long)(now.tv_sec - inode->i_atime.tv_sec)< 0)
>> + return 1;
>> + /*
>> + * Is the previous atime value old than a day? If yes,
>> * update atime:
>> */
>> if ((long)(now.tv_sec - inode->i_atime.tv_sec)>= 24*60*60)
>>
> I don't think this is a good plan for cluster filesystems, since if the
> times on the nodes are not exactly synchronised (we do highly recommend
> people run ntp or similar) then this might lead to excessive atime
> updating. The current behaviour is to ignore atimes which are in the
> future for exactly this reason,
>
I agreed in theory. Anyway, a two-way update may cause shake in some
case. Like a cluster environment with time gap between cluster members.
But future atime also is a trouble things i think. Of course, I hope a
clever patch to fix them all.

Thanks
yangsheng


\
 
 \ /
  Last update: 2011-01-03 17:47    [W:0.068 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site