If atime has been wrong set to future, then it cannot
be updated back to current time.
fs/inode.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/fs/inode.c b/fs/inode.c
index da85e56..9cf7375 100644
@@ -1446,6 +1446,8 @@ sector_t bmap(struct inode *inode, sector_t block)
+#define RELATIME_MARGIN (24 * 60 * 60)
* With relative atime, only update atime if the previous atime is
* earlier than either the ctime or mtime or if at least a day has
@@ -1469,10 +1471,16 @@ static int relatime_need_update(struct vfsmount *mnt, struct inode *inode,
- * 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) < -RELATIME_MARGIN)
+ 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)
+ if ((long)(now.tv_sec - inode->i_atime.tv_sec) >= RELATIME_MARGIN)
* Good, we can skip the atime update:
I recall the consensus was that a /proc tunable was "too much" for the initial patch. An atime update interval of 1 day is sufficient for most applications, since they run daily to do file access scanning. The #define was added because I dislike having multiple hard-coded values in any code.
I haven't heard of any complaints about the relatime update frequency, except for this "atime in the future" problem, so until that happens we may as well leave it as-is.