Skip to contentSkip to conversation

ext4 lazytime: ctime of some files changed

DISCUSSION Jörg-Volker Peetz 3 participants 16 messages May 13, 2015 – May 23, 2015

Subsystems (2)
VFS ext4 file system
lore
Share & tools
lore

Jörg-Volker Peetz

author
#0 lore raw

Dear Ted,

on my laptop with ext4 fs (on SSD) I started to try the lazytime mount option using a self compiled kernel 4.0.2 on a debian system with mount version 2.26.2. Before that, I've used the noatime mount option.

After restarting the system with an adapted /etc/fstab file and the kernel parameter "rootflags=lazytime", the relatime mount option was also set. I changed that by commanding "mount -o remount,strictatime /", etc. By accident, I noticed that some files had a modified ctime and mtime although they were not changed or modified.

Has anybody else experienced that? Do I miss a patch?

Mount options in fstab: nobarrier,lazytime,errors=remount-ro
The filesystems are ext4 on a primary partition of the SSD with default mount option journal_data_writeback. I created them in Feb 2011.

By the way, the command "mount -o remount,lazytime /" does not do the switch to lazytime.

And thanks for your tireless work on Linux.

Signature · 2 lines
Regards,
jvp.
author
#1 lore raw

Jörg-Volker Peetz wrote on 05/13/2015 11:35:

Quoted 14 lines

Dear Ted,

on my laptop with ext4 fs (on SSD) I started to try the lazytime mount option using a self compiled kernel 4.0.2 on a debian system with mount version 2.26.2. Before that, I've used the noatime mount option.

After restarting the system with an adapted /etc/fstab file and the kernel parameter "rootflags=lazytime", the relatime mount option was also set. I changed that by commanding "mount -o remount,strictatime /", etc. By accident, I noticed that some files had a modified ctime and mtime although they were not changed or modified.

Has anybody else experienced that? Do I miss a patch?

Quoted 9 lines

Mount options in fstab: nobarrier,lazytime,errors=remount-ro
The filesystems are ext4 on a primary partition of the SSD with default mount option journal_data_writeback. I created them in Feb 2011.

By the way, the command "mount -o remount,lazytime /" does not do the switch to lazytime.

And thanks for your tireless work on Linux.

After writing the above, I encountered another accident regarding two files of the emacs24 package of which the mtime got changed.

I tried to repair this by using versions of the two files with the correct mtime in the /tmp directory and commanded

Quoted 1 line

touch -r /tmp/debian-ispell.elc

/usr/share/emacs24/site-lisp/dictionaries-common/debian-ispell.elc

Quoted 1 line

touch -r /tmp/ess-noweb-font-lock-mode.elc

/usr/share/emacs24/site-lisp/ess/ess-noweb-font-lock-mode.elc

A few hours later I unpacked and tested a tar archive by commanding s.t. like

Quoted 4 lines

tar xf linux-4.0.tar.xz
sync
echo 3 >/proc/sys/vm/drop_caches
tar df linux-4.0.tar.xz

Thereafter, the two emacs package files again had a wrong mtime (which by the way shows when I start emacs).

Could this be due to the lazytime mount option?

Signature · 8 lines
Regards,
jvp.


--
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
maintainer
#2 lore raw
Quoted 5 lines · Jörg-Volker Peetz

Thereafter, the two emacs package files again had a wrong mtime (which by the way shows when I start emacs).

Could this be due to the lazytime mount option?

I think I found the problem. My bad. Can you verify that this solves the problem for you?

From 8f4d855839179f410fa910a26eb81d646d628f26 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <[email protected]>
Date: Thu, 14 May 2015 18:19:01 -0400
Subject: [PATCH] ext4: fix lazytime optimization

We had a fencepost error in the lazytime optimization which means that timestamp would get written to the wrong inode.

Cc [email protected]
Signed-off-by Theodore Ts'o <[email protected]>
---
 fs/ext4/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ext4/inode.c +1 -1
index 55b187c..0554b0b 100644
@@ -4345,7 +4345,7 @@ static void ext4_update_other_inodes_time(struct super_block *sb,
 	int inode_size = EXT4_INODE_SIZE(sb);
 
 	oi.orig_ino = orig_ino;
-	ino = orig_ino & ~(inodes_per_block - 1);
+	ino = (orig_ino & ~(inodes_per_block - 1)) + 1;
 	for (i = 0; i < inodes_per_block; i++, ino++, buf += inode_size) {
 		if (ino == orig_ino)
 			continue;
Signature · 6 lines
2.3.0

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
author
#3 lore raw

Theodore Ts'o wrote on 05/15/2015 00:20:

Quoted 10 lines · Jörg-Volker Peetz
Quoted 5 lines

Thereafter, the two emacs package files again had a wrong mtime (which by the way shows when I start emacs).

Could this be due to the lazytime mount option?

I think I found the problem. My bad. Can you verify that this solves the problem for you?

I'll try the patch today after repairing most of the timestamps from backup to have a reference.

Signature · 7 lines
Regards,
Jörg.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
author
#4 lore raw
In reply to Theodore Ts'o

Theodore Ts'o wrote on 05/15/2015 00:20:

Quoted 10 lines · Jörg-Volker Peetz
Quoted 5 lines

Thereafter, the two emacs package files again had a wrong mtime (which by the way shows when I start emacs).

Could this be due to the lazytime mount option?

I think I found the problem. My bad. Can you verify that this solves the problem for you?

Meanwhile I've kernel version 4.0.3 with your patch on top and

$ grep -E '(root|sda)' /proc/mounts
/dev/root / ext4 rw,lazytime,nobarrier,errors=remount-ro 0 0
/dev/sda2 /home ext4 rw,lazytime,nobarrier,errors=remount-ro 0 0

running nearly two hours without any file timestamp related anomalies while doing some file activity and a sync from time to time :-) Thanks for caring.

Quoted 28 lines

From 8f4d855839179f410fa910a26eb81d646d628f26 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <[email protected]>
Date: Thu, 14 May 2015 18:19:01 -0400
Subject: [PATCH] ext4: fix lazytime optimization

We had a fencepost error in the lazytime optimization which means that timestamp would get written to the wrong inode.

Cc [email protected]
Signed-off-by Theodore Ts'o <[email protected]>
---
 fs/ext4/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/ext4/inode.c +1 -1
index 55b187c..0554b0b 100644
@@ -4345,7 +4345,7 @@ static void ext4_update_other_inodes_time(struct super_block *sb,
 	int inode_size = EXT4_INODE_SIZE(sb);
 
 	oi.orig_ino = orig_ino;
-	ino = orig_ino & ~(inodes_per_block - 1);
+	ino = (orig_ino & ~(inodes_per_block - 1)) + 1;
 	for (i = 0; i < inodes_per_block; i++, ino++, buf += inode_size) {
 		if (ino == orig_ino)
 			continue;
Signature · 7 lines
Regards,
Jörg.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
maintainer
#5 lore raw
Quoted 3 lines · Jörg-Volker Peetz

running nearly two hours without any file timestamp related anomalies while doing some file activity and a sync from time to time :-) Thanks for caring.

Many thanks for the bug report! :-)

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

author
#6 lore raw

Hi Ted,

Theodore Ts'o wrote on 05/16/2015 01:11:

Quoted 8 lines · Jörg-Volker Peetz
Quoted 3 lines

running nearly two hours without any file timestamp related anomalies while doing some file activity and a sync from time to time :-) Thanks for caring.

Many thanks for the bug report! :-)

- Ted

after a few days of running the patch, I seem to have again two files with changed mtime without touching them (only reading by rsync).

I took a look into the file fs/ext4/inode.c and saw this code in function __ext4_get_inode_loc(struct inode *inode,
struct ext4_iloc *iloc, int in_mem)
:

		if (in_mem) {
			struct buffer_head *bitmap_bh;
			int i, start;

			start = inode_offset & ~(inodes_per_block - 1);

			/* Is the inode bitmap in cache? */
			bitmap_bh = sb_getblk(sb, ext4_inode_bitmap(sb, gdp));

I'm not sure, if this is relevant, but just for curiosity, why does "start" here not need a "+ 1"?

Signature · 8 lines
Regards,
Jörg.


--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
author
#7 lore raw

Jörg-Volker Peetz wrote on 05/20/2015 10:48:
<snip>

Quoted 3 lines

after a few days of running the patch, I seem to have again two files with changed mtime without touching them (only reading by rsync).

<snip>
I can affirm this error, but am not sure where to hunt. I'm using several USB drives in a cycle for backup.
I have a directory with a file originally older than a few years. Mount options are

$ grep sda /proc/mounts
/dev/sda2 /home ext4 rw,lazytime,relatime,nobarrier,errors=remount-ro 0 0

(using lazytime with relatime).
As reported, while I started using lazytime, this file's mtime got changed. I reset the mtime with the "touch -r <intact_copy> <file>" command. After a backup to one of the USB drives with something like

$ rsync -acv --exclude-from=<file> --delete-excluded <SRC> <DEST_ON_USB_DRIVE>

the namely file had its mtime changed on the *source* device (the USB drive has an ext4 fs mounted without the lazytime option).
I reset that again on the source SSD using "touch". Another file in the same was also modified.

Next backup on another USB drive, same thing.
I took a look into the file list on the backup medium before the backup. There the file also had a different mtime, but not the same mtime the file got after the backup.

I'm confused.
Any idea?

Signature · 8 lines
Regards,
Jörg.


--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
maintainer
#8 lore raw
In reply to Jörg-Volker Peetz
Quoted 8 lines · Jörg-Volker Peetz

on my laptop with ext4 fs (on SSD) I started to try the lazytime mount option using a self compiled kernel 4.0.2 on a debian system with mount version 2.26.2. Before that, I've used the noatime mount option.

After restarting the system with an adapted /etc/fstab file and the kernel parameter "rootflags=lazytime", the relatime mount option was also set. I changed that by commanding "mount -o remount,strictatime /", etc.

The lazytime flag is independent of strictatime/relatime/noatime. And the default is relatime. So when you replaced noatime with lazytime, it's not surprising that you saw the relatime mount option being set.

Quoted 4 lines

By accident, I noticed that some files had a modified ctime and mtime although they were not changed or modified.

Has anybody else experienced that? Do I miss a patch?

I haven't seen this myself.

Quoted 6 lines

Mount options in fstab: nobarrier,lazytime,errors=remount-ro
The filesystems are ext4 on a primary partition of the SSD with default mount option journal_data_writeback. I created them in Feb 2011.

By the way, the command "mount -o remount,lazytime /" does not do the switch to lazytime.

# grep sda3 /proc/mounts
/dev/sda3 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
# mount -o remount,lazytime /
# grep sda3 /proc/mounts
/dev/sda3 / ext4 rw,lazytime,relatime,errors=remount-ro,data=ordered 0 0
# uname -a
Linux closure 4.1.0-rc2-11633-gef8a5d0 #125 SMP Tue May 5 21:21:08 EDT 2015 x86_64 GNU/Linux

- Ted
--
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

author
#9 lore raw

Theodore Ts'o wrote on 05/14/2015 04:17:

Quoted 6 lines · Jörg-Volker Peetz
Quoted 3 lines

By the way, the command "mount -o remount,lazytime /" does not do the switch to lazytime.

Quoted 7 lines
# grep sda3 /proc/mounts
/dev/sda3 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
# mount -o remount,lazytime /
# grep sda3 /proc/mounts
/dev/sda3 / ext4 rw,lazytime,relatime,errors=remount-ro,data=ordered 0 0
# uname -a
Linux closure 4.1.0-rc2-11633-gef8a5d0 #125 SMP Tue May 5 21:21:08 EDT 2015 x86_64 GNU/Linux
# uname -a
Linux fehu 4.0.2 #1 SMP Thu May 7 00:09:53 CEST 2015 x86_64 GNU/Linux
# grep sda2 /proc/mounts
/dev/sda2 /home ext4 rw,noatime,nobarrier,errors=remount-ro 0 0
# mount -o remount,lazytime /home
# grep sda2 /proc/mounts
/dev/sda2 /home ext4 rw,noatime,nobarrier,errors=remount-ro 0 0
# mount --version
mount from util-linux 2.26.2 (libmount 2.26.0: selinux, assert, debug)

Also switching to relatime does not work with the mount command. Could it be a problem with the mount package of debian?

Signature · 8 lines
Regards,
jvp.


--
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
maintainer
#10 lore raw
Quoted 3 lines · Jörg-Volker Peetz

Also switching to relatime does not work with the mount command. Could it be a problem with the mount package of debian?

I'm using Debian Jessie:

ii mount 2.25.2-6 amd64 Tools for mounting and manipulating filesystem

The other difference might be what you and I have in our /etc/fstab? I have:

LABEL=closure-root / ext4 errors=remount-ro 0 1

Can you also try something like this?

# strace -o /tmp/st mount -o remount,nolazytime /
# grep ^mount /tmp/st
mount("/dev/sda3", "/", 0x1f21250, MS_MGC_VAL|MS_REMOUNT, "errors=remount-ro,lazytime") = 0

Cheers,

- Ted
--
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

author
#11 lore raw

Theodore Ts'o wrote on 05/14/2015 14:38:

Quoted 7 lines · Jörg-Volker Peetz
Quoted 3 lines

Also switching to relatime does not work with the mount command. Could it be a problem with the mount package of debian?

I'm using Debian Jessie:

I'm using a mixture of testing and sid with mount, util-linux, etc. version 2.26.2-2.

Quoted 7 lines

ii mount 2.25.2-6 amd64 Tools for mounting and manipulating filesystem

The other difference might be what you and I have in our /etc/fstab? I have:

LABEL=closure-root / ext4 errors=remount-ro 0 1

Here:
UUID=7e13aca5-... / ext4 nobarrier,noatime,errors=remount-ro 0 2

Quoted 6 lines

Can you also try something like this?

# strace -o /tmp/st mount -o remount,nolazytime /
# grep ^mount /tmp/st
mount("/dev/sda3", "/", 0x1f21250, MS_MGC_VAL|MS_REMOUNT, "errors=remount-ro,lazytime") = 0

mount("/dev/sda1", "/", 0x1488780, MS_MGC_VAL|MS_REMOUNT|MS_NOATIME, "nobarrier,errors=remount-ro") = 0

Quoted 3 lines

Cheers,

- Ted

Thank you for your support.

Signature · 8 lines
Jörg.



--
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
author
#12 lore raw

Jörg-Volker Peetz wrote on 05/14/2015 14:58:

Quoted 13 lines

Theodore Ts'o wrote on 05/14/2015 14:38:

Quoted 7 lines · Jörg-Volker Peetz
Quoted 3 lines

Also switching to relatime does not work with the mount command. Could it be a problem with the mount package of debian?

I'm using Debian Jessie:

I'm using a mixture of testing and sid with mount, util-linux, etc. version 2.26.2-2.

Quoted 2 lines

ii mount 2.25.2-6 amd64 Tools for mounting and manipulating filesystem

Quoted 8 lines
Quoted 5 lines

The other difference might be what you and I have in our /etc/fstab? I have:

LABEL=closure-root / ext4 errors=remount-ro 0 1

Here:
UUID=7e13aca5-... / ext4 nobarrier,noatime,errors=remount-ro 0 2

Typo here, is actually
UUID=7e13aca5-... / ext4 nobarrier,noatime,errors=remount-ro 0 1

Quoted 6 lines
Quoted 6 lines

Can you also try something like this?

# strace -o /tmp/st mount -o remount,nolazytime /
# grep ^mount /tmp/st
mount("/dev/sda3", "/", 0x1f21250, MS_MGC_VAL|MS_REMOUNT, "errors=remount-ro,lazytime") = 0
Quoted 8 lines

mount("/dev/sda1", "/", 0x1488780, MS_MGC_VAL|MS_REMOUNT|MS_NOATIME, "nobarrier,errors=remount-ro") = 0

Quoted 3 lines

Cheers,

- Ted

Thank you for your support.

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

author
#13 lore raw
In reply to Jörg-Volker Peetz

Jörg-Volker Peetz wrote on 05/14/2015 14:58:

Quoted 21 lines

Theodore Ts'o wrote on 05/14/2015 14:38:

Quoted 7 lines · Jörg-Volker Peetz
Quoted 3 lines

Also switching to relatime does not work with the mount command. Could it be a problem with the mount package of debian?

I'm using Debian Jessie:

I'm using a mixture of testing and sid with mount, util-linux, etc. version 2.26.2-2.

Quoted 7 lines

ii mount 2.25.2-6 amd64 Tools for mounting and manipulating filesystem

The other difference might be what you and I have in our /etc/fstab? I have:

LABEL=closure-root / ext4 errors=remount-ro 0 1

Here:
UUID=7e13aca5-... / ext4 nobarrier,noatime,errors=remount-ro 0 2

Quoted 9 lines
Quoted 6 lines

Can you also try something like this?

# strace -o /tmp/st mount -o remount,nolazytime /
# grep ^mount /tmp/st
mount("/dev/sda3", "/", 0x1f21250, MS_MGC_VAL|MS_REMOUNT, "errors=remount-ro,lazytime") = 0

mount("/dev/sda1", "/", 0x1488780, MS_MGC_VAL|MS_REMOUNT|MS_NOATIME, "nobarrier,errors=remount-ro") = 0

After re-reading it again, I should clarify that I meanwhile rebooted with noatime. Maybe then, it is more helpful to show the output of

# strace -o /tmp/st mount -o remount,lazytime /
# grep ^mount /tmp/st
mount("/dev/sda1", "/", 0x10a0780, MS_REMOUNT|MS_NOATIME|0x2000000,
"nobarrier,errors=remount-ro") = 0
Signature · 8 lines
Regards,
Jörg.


--
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
author
#14 lore raw
In reply to Theodore Ts'o

[forgot to Cc to you]
Theodore Ts'o wrote on 05/14/2015 04:17:

Quoted 6 lines · Jörg-Volker Peetz
Quoted 3 lines

By the way, the command "mount -o remount,lazytime /" does not do the switch to lazytime.

Quoted 7 lines
# grep sda3 /proc/mounts
/dev/sda3 / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
# mount -o remount,lazytime /
# grep sda3 /proc/mounts
/dev/sda3 / ext4 rw,lazytime,relatime,errors=remount-ro,data=ordered 0 0
# uname -a
Linux closure 4.1.0-rc2-11633-gef8a5d0 #125 SMP Tue May 5 21:21:08 EDT 2015 x86_64 GNU/Linux
# uname -a
Linux fehu 4.0.2 #1 SMP Thu May 7 00:09:53 CEST 2015 x86_64 GNU/Linux
# grep sda2 /proc/mounts
/dev/sda2 /home ext4 rw,noatime,nobarrier,errors=remount-ro 0 0
# mount -o remount,lazytime /home
# grep sda2 /proc/mounts
/dev/sda2 /home ext4 rw,noatime,nobarrier,errors=remount-ro 0 0
# mount --version
mount from util-linux 2.26.2 (libmount 2.26.0: selinux, assert, debug)

Also switching to relatime does not work with the mount command. Could it be a problem with the mount package of debian?

Signature · 8 lines
Regards,
jvp.


--
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
#15 lore raw
In reply to Jörg-Volker Peetz
Quoted 2 lines · Jörg-Volker Peetz

By the way, the command "mount -o remount,lazytime /" does not do the switch to lazytime.

Had the same problem, found the regression:

http://article.gmane.org/gmane.comp.file-systems.ext4/48663

Solution: downgrade to util-linux-2.25.2.

cheers
Holger

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