relatime: Make atime updates more useful

+#define MS_NORELATIME (1<<24) /* Disable relatie even if the default */

Allow the kernel to enable relatime on all mounts by default. This can be configured at build time or by a kernel parameter or sysctl. Also add an MS_NORELATIME mount option to allow the default to be overridden for specific mount points.

Signed-off-by Matthew Garrett <[email protected]>

---

Updated version of Ingo's patch, but adds MS_NORELATIME. util-linux will need updating to match if this is merged.

Documentation/kernel-parameters.txt +0 -0

index e0f346d..eba3b07 100644

Documentation/kernel-parameters.txt +4 -0

 	vt.default_utf8=
 			[VT]
 			Format=<0|1>

@@ -1847,6 +1851,10 @@ and is between 256 and 4096 characters. It is defined in the file
 			[KNL, SMP] Set scheduler's default relax_domain_level.
 			See Documentation/cpusets.txt.
 
+	relatime_interval=
+			[FS] relative atime update frequency, in seconds.
+			(default: 1 day: 86400 seconds)
+
 	reserve=	[KNL,BUGS] Force the kernel to ignore some iomem area
 
 	reservetop=	[X86-32]

fs/Kconfig +23 -0

index 522469a..fcd3d48 100644
@@ -1546,6 +1546,29 @@ config 9P_FS
 
 endif # NETWORK_FILESYSTEMS
 
+config DEFAULT_RELATIME
+	bool "Mount all filesystems with relatime by default"
+	default y
+	help
+	  If you say Y here, all your filesystems will be mounted
+	  with the "relatime" mount option. This eliminates many atime
+	  ('file last accessed' timestamp) updates (which otherwise
+	  is performed on every file access and generates a write
+	  IO to the inode) and thus speeds up IO. Atime is still updated,
+	  but only once per day.
+
+	  The mtime ('file last modified') and ctime ('file created')
+	  timestamp are unaffected by this change.
+
+	  Use the "norelatime" kernel boot option to turn off this
+	  feature.
+
+config DEFAULT_RELATIME_VAL
+	int
+	default "1" if DEFAULT_RELATIME
+	default "0"
+
+
 if BLOCK
 menu "Partition Types"
 

fs/inode.c +11 -0

index 348fa16..51e9ae1 100644
@@ -1185,6 +1185,17 @@ EXPORT_SYMBOL(bmap);
 int relatime_interval __read_mostly = 24*60*60;
 
 /*
+ * Allow overriding the default relatime value on the kernel command line
+ */
+static int __init set_relatime_interval(char *str)
+{
+	get_option(&str, &relatime_interval);
+
+	return 1;
+}
+__setup("relatime_interval=", set_relatime_interval);
+
+/*
  * With relative atime, only update atime if the
  * previous atime is earlier than either the ctime or
  * mtime.

fs/namespace.c +0 -0

index 65b3dc8..76f30b5 100644
@@ -1883,6 +1883,24 @@ int copy_mount_options(const void __user * data, unsigned long *where)
 }
 
 /*

fs/namespace.c +13 -0

+		"default relative atime updates: %s.\n",
+		default_relatime ? "enabled" : "disabled");
+
+	return 1;
+}
+__setup("default_relatime=", set_default_relatime);
+
+/*
  * Flags is a 32-bit value that allows up to 31 non-fs dependent flags to
  * be given to the mount() call (ie: read-only, no-dev, no-suid etc).
  *

@@ -1930,6 +1948,11 @@ long do_mount(char *dev_name, char *dir_name, char *type_page,
 		mnt_flags |= MNT_NODIRATIME;
 	if (flags & MS_RELATIME)
 		mnt_flags |= MNT_RELATIME;
+	else if (default_relatime &&
+		 !(flags & (MS_NOATIME | MS_NODIRATIME | MS_NORELATIME))) {
+		mnt_flags |= MNT_RELATIME;
+		flags |= MS_RELATIME;
+	}
 	if (flags & MS_RDONLY)
 		mnt_flags |= MNT_READONLY;
 

include/linux/fs.h +0 -0

index 0dcdd94..a4db010 100644

include/linux/fs.h +0 -0

 #define MS_ACTIVE	(1<<30)
 #define MS_NOUSER	(1<<31)

Add support for defaulting to relatime

Allow the kernel to enable relatime on all mounts by default. This can be configured at build time or by a kernel parameter or sysctl. Also add a MS_NORELATIME mount option to allow the default to be overridden for specific mount points.

Signed-off-by Matthew Garrett <[email protected]>

---

Incorporates Randy's suggestion to change default_relatime to relatime_default, along with a couple of typographical fixes

Also add a MS_NORELATIME mount option

+#define MS_NORELATIME (1<<24) /* Disable relatime even if the default */

Quoted 1 line · Matthew Garrett

Also add a MS_NORELATIME mount option

[...]

Quoted 1 line

+#define MS_NORELATIME (1<<24) /* Disable relatime even if the default */

CC [email protected]

Quoted 3 lines · Karel Zak

Quoted 1 line · Matthew Garrett

Also add a MS_NORELATIME mount option

[...]

Quoted 3 lines

Quoted 1 line

+#define MS_NORELATIME (1<<24) /* Disable relatime even if the default */

CC [email protected]

That's useful. Without this, to disable relatime you needed to:

echo 0 > /proc/sys/fs/default_relatime
mount -o remount,atime /mnt/point/

Putting in extra flags to allow the kernel and user space to fight each other over mount defaults is a recipe for disaster. Take your userspace mount command and beat it up appropriately. If you want a mount command that defaults to relatime then ship a mount command that does.

Make relatime smarter

Allow atime to be updated once per day even with relatime. This lets utilities like tmpreaper (which delete files based on last access time) continue working. The time between atime updates can be configured at boot with the relatime_interval kernel argument, or at runtime through /proc

Documentation/kernel-parameters.txt and is between 256 and 4096 characters. It is defined in the file · line 1852

Quoted 3 lines · Matthew Garrett

Documentation/kernel-parameters.txt +3 -0

+	relatime_interval=
+			[FS] relative atime update frequency, in seconds.
+			(default: 1 day: 86400 seconds)

The one problem with a 1-day default is that cron jobs like updatedb will revert to updating the atime on every single file every day. It would be better to make it slightly more than 1 day (e.g. 25h) to avoid this and at least defer atime updates to every other day for files that are not otherwise accessed except by cron.

The one problem with a 1-day default is that cron jobs like updatedb will revert to updating the atime on every single file every day. It would be better to make it slightly more than 1 day (e.g. 25h) to avoid this and at least defer atime updates to every other day for files that are not otherwise accessed except by cron.

The one problem with a 1-day default is that cron jobs like updatedb will revert to updating the atime on every single file every day. It would be better to make it slightly more than 1 day (e.g. 25h) to avoid this and at least defer atime updates to every other day for files that are not otherwise accessed except by cron.

The time between atime updates can be configured at boot
with the relatime_interval kernel argument, or at runtime through a sysctl.

Quoted 2 lines · Matthew Garrett

The time between atime updates can be configured at boot
with the relatime_interval kernel argument, or at runtime through a sysctl.

Shouldn't it be a per-mount value, with defaults coming from the sysctl?

Quoted 5 lines · Jamie Lokier

Quoted 2 lines · Matthew Garrett

The time between atime updates can be configured at boot
with the relatime_interval kernel argument, or at runtime through a sysctl.

Shouldn't it be a per-mount value, with defaults coming from the sysctl?

Perhaps a more sensible question would be "Why make it configurable at all?" What's wrong with hardcoding 24 hours? Or, to put it another way, who wants to change it from 24 hours, and why?

Quoted 5 lines · Jamie Lokier

Quoted 2 lines · Matthew Garrett

The time between atime updates can be configured at boot
with the relatime_interval kernel argument, or at runtime through a sysctl.

Shouldn't it be a per-mount value, with defaults coming from the sysctl?

Perhaps a more sensible question would be "Why make it configurable at

all?" What's wrong with hardcoding 24 hours? Or, to put it another way, who wants to change it from 24 hours, and why?

Quoted 8 lines · Matthew Wilcox

Quoted 5 lines · Jamie Lokier

Quoted 2 lines · Matthew Garrett

The time between atime updates can be configured at boot
with the relatime_interval kernel argument, or at runtime through a sysctl.

Shouldn't it be a per-mount value, with defaults coming from the sysctl?

Perhaps a more sensible question would be "Why make it configurable at

this is GNOME-mentality :-)

Quoted 2 lines

all?" What's wrong with hardcoding 24 hours? Or, to put it another way, who wants to change it from 24 hours, and why?

Why do you think that 24 hours is the right default value? Do you have any logical argument for this setting?

Documentation/kernel-parameters.txt and is between 256 and 4096 characters. It is defined in the file · line 1852

Quoted 3 lines

Documentation/kernel-parameters.txt +3 -0

+	relatime_interval=
+			[FS] relative atime update frequency, in seconds.
+			(default: 1 day: 86400 seconds)

What about leap seconds ;)

Quoted 5 lines · Alan Cox

Documentation/kernel-parameters.txt and is between 256 and 4096 characters. It is defined in the file · line 1852

Quoted 3 lines

Documentation/kernel-parameters.txt +3 -0

+	relatime_interval=
+			[FS] relative atime update frequency, in seconds.
+			(default: 1 day: 86400 seconds)

What about leap seconds ;)

More generally - is the relatime_interval in "monotonic" seconds, or in gettimeofday seconds which are changed by clock updates?

Add support for defaulting to relatime

Allow the kernel to enable relatime on all mounts by default. This can be configured at build time or by a kernel parameter or sysctl. Also add a MS_NORELATIME mount option to allow the default to be overridden for specific mount points.

Quoted 6 lines · Matthew Garrett

Add support for defaulting to relatime

Allow the kernel to enable relatime on all mounts by default. This can be configured at build time or by a kernel parameter or sysctl. Also add a MS_NORELATIME mount option to allow the default to be overridden for specific mount points.

NACK. Please just do it in fstab.

Yes, that's what I was wondering. No /proc thingy, no new Kconfig entries, no __setup() thing. Just

	mount -o relatime=$((24*60*60)) /dev/sda1 /mnt/point
	mount -o remount,relatime=$((24*60*60)) /dev/sda1 /mnt/point

That would imply that relatime could be different per-mountpoint.

I favour not making it configurable at all.

Allow atime to be updated once per day even with relatime enabled. This lets utilities like tmpreaper (which deletes files based on last access time) continue working.

...and check the tmpreaper manpage, you will notice that tmpreaper can be configured as well. So relatime has a default timeout of T and tmpreaper is configured to delete files after 1/2 T (never mind what T might be), the system breaks. Guessing a value of T that is good enough for everyone is a complicated business, so one configurable makes sense imo.

One per mountpoint is rather silly, of course.

I don't see why there is an objection to per-mountpoint. Andrew Morton's syntax: mount /dev/foo /mnt/bar -o relatime=86400 looks natural to me.

Quoted 3 lines · Jamie Lokier

I don't see why there is an objection to per-mountpoint. Andrew Morton's syntax: mount /dev/foo /mnt/bar -o relatime=86400 looks natural to me.

If somebody feels that this functionality would be useful, they're welcome to write it.

A global default doesn't preclude per-mountpoint
settings. This patch makes the existing kernel code more useful and so is worthwhile on its own, even if it doesn't scratch everyone's itch.

The standard, usual, expected way of modifying a filesystem's behaviour is via mount options. This is also quite flexible.

Is there some extraordinary reason why the standard interface is not to be used here?

Quoted 5 lines · Andrew Morton

The standard, usual, expected way of modifying a filesystem's behaviour is via mount options. This is also quite flexible.

Is there some extraordinary reason why the standard interface is not to be used here?

Because it would have to be managed (and consulted) per ... what? vfsmount? superblock?

This is featuritis gone MAD.

Quoted 5 lines · Andrew Morton

The standard, usual, expected way of modifying a filesystem's behaviour is via mount options. This is also quite flexible.

Is there some extraordinary reason why the standard interface is not to be used here?

Because it would have to be managed (and consulted) per ... what? vfsmount? superblock? This is featuritis gone MAD.

I'll take my bikeshed in teal, stippled with cornsilk.

The standard, usual, expected way of modifying a filesystem's behaviour is via mount options. This is also quite flexible.

Is there some extraordinary reason why the standard interface is not to be used here?

let me ask this:
Has anmyone ever had the desire to change the default of 1 day of relatime? Ever?

Quoted 3 lines · On Sat, 29 Nov 2008 19:02:45 +0000 Matthew Garrett <[email protected]> wrote:

A global default doesn't preclude per-mountpoint
settings. This patch makes the existing kernel code more useful and so is worthwhile on its own, even if it doesn't scratch everyone's itch.

The standard, usual, expected way of modifying a filesystem's behaviour is via mount options. This is also quite flexible.

Make relatime smarter

Allow atime to be updated once per day even with relatime. This lets utilities like tmpreaper (which delete files based on last access time) continue working.

---

Subset of Ingo's original patch, rediffed against current git

Allow atime to be updated once per day even with relatime enabled. This lets utilities like tmpreaper (which deletes files based on last access time) continue working.

Signed-off-by Matthew Garrett <[email protected]>

---

Updated version of Ingo's patch from last year - this section is identical.

commit 2c145e187600ca961715fa82ae3ae7919d744bc9

Author: Matthew Garrett <[email protected]>
Date:   Wed Nov 26 17:44:07 2008 +0000

Make relatime smarter

Allow atime to be updated once per day even with relatime. This lets utilities like tmpreaper (which delete files based on last access time) continue working.

fs/inode.c +14 -0

+/*
+ * With relative atime, only update atime if the
+ * previous atime is earlier than either the ctime or
+ * mtime.
+ */
+static int relatime_need_update(struct inode *inode, struct timespec now)
+{
+	/*
+	 * Is mtime younger than atime? If yes, update atime:
+	 */
+	if (timespec_compare(&inode->i_mtime, &inode->i_atime) >= 0)
+		return 1;
+	/*
+	 * Is ctime younger than atime? If yes, update atime:

fs/inode.c +10 -9

+	/*
+	 * Good, we can skip the atime update:
+	 */
+	return 0;
+}
+
 /**
  *	touch_atime	-	update the access time
  *	@mnt: mount the inode is accessed on

@@ -1206,17 +1241,12 @@ void touch_atime(struct vfsmount *mnt, struct dentry *dentry)
 		goto out;
 	if ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode))
 		goto out;
-	if (mnt->mnt_flags & MNT_RELATIME) {
-		/*
-		 * With relative atime, only update atime if the previous
-		 * atime is earlier than either the ctime or mtime.
-		 */
-		if (timespec_compare(&inode->i_mtime, &inode->i_atime) < 0 &&
-		    timespec_compare(&inode->i_ctime, &inode->i_atime) < 0)
-			goto out;
-	}
 
 	now = current_fs_time(inode->i_sb);
+
+	if (mnt->mnt_flags & MNT_RELATIME)
+		if (!relatime_need_update(inode, now))
+			goto out;
 	if (timespec_equal(&inode->i_atime, &now))
 		goto out;

Allow atime to be updated once per day even with relatime. This lets utilities like tmpreaper (which delete files based on last access time) continue working.

Signed-off-by Matthew Garrett <[email protected]>

Acked-by Ingo Molnar <[email protected]>

Acked-by Alan Cox <[email protected]>

---

I've removed the adjustable time code, since nobody's come up with a terribly good use case for it. This makes relatime more useful in the generic case - there may be situations where it still doesn't satisfy people, but that's not a regression over the current situation.

fs/inode.c +38 -9

index 0487ddb..057c92b 100644
@@ -1179,6 +1179,40 @@ sector_t bmap(struct inode * inode, sector_t block)
 }
 EXPORT_SYMBOL(bmap);
 
+/*
+ * 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
+ * passed since the last atime update.
+ */
+static int relatime_need_update(struct vfsmount *mnt, struct inode *inode,
+			     struct timespec now)
+{
+
+	if (!(mnt->mnt_flags & MNT_RELATIME))
+		return 1;
+	/*
+	 * Is mtime younger than atime? If yes, update atime:
+	 */
+	if (timespec_compare(&inode->i_mtime, &inode->i_atime) >= 0)
+		return 1;
+	/*
+	 * Is ctime younger than atime? If yes, update atime:
+	 */
+	if (timespec_compare(&inode->i_ctime, &inode->i_atime) >= 0)
+		return 1;
+
+	/*
+	 * Is the previous atime value older than a day? If yes,
+	 * update atime:
+	 */
+	if ((long)(now.tv_sec - inode->i_atime.tv_sec) >= 24*60*60)
+		return 1;
+	/*
+	 * Good, we can skip the atime update:
+	 */
+	return 0;
+}
+
 /**
  *	touch_atime	-	update the access time
  *	@mnt: mount the inode is accessed on

@@ -1206,17 +1240,12 @@ void touch_atime(struct vfsmount *mnt, struct dentry *dentry)
 		goto out;
 	if ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode))
 		goto out;
-	if (mnt->mnt_flags & MNT_RELATIME) {
-		/*
-		 * With relative atime, only update atime if the previous
-		 * atime is earlier than either the ctime or mtime.
-		 */
-		if (timespec_compare(&inode->i_mtime, &inode->i_atime) < 0 &&
-		    timespec_compare(&inode->i_ctime, &inode->i_atime) < 0)
-			goto out;
-	}
 
 	now = current_fs_time(inode->i_sb);
+
+	if (!relatime_need_update(mnt, inode, now))
+		goto out;
+
 	if (timespec_equal(&inode->i_atime, &now))
 		goto out;
 

Signature · 5 lines

Matthew Garrett | [email protected]
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html