On Wed, May 13, 2015 at 06:20:35PM +0200, J?rg-Volker Peetz wrote:
>
> 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(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 55b187c..0554b0b 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -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;
--
2.3.0
Theodore Ts'o wrote on 05/15/2015 00:20:
> On Wed, May 13, 2015 at 06:20:35PM +0200, J?rg-Volker Peetz wrote:
>>
>> 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.
--
Regards,
J?rg.
Theodore Ts'o wrote on 05/15/2015 00:20:
> On Wed, May 13, 2015 at 06:20:35PM +0200, J?rg-Volker Peetz wrote:
>>
>> 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.
> 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(-)
>
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 55b187c..0554b0b 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -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;
>
--
Regards,
J?rg.
On Fri, May 15, 2015 at 05:14:10PM +0200, J?rg-Volker Peetz wrote:
> 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
Hi Ted,
Theodore Ts'o wrote on 05/16/2015 01:11:
> On Fri, May 15, 2015 at 05:14:10PM +0200, J?rg-Volker Peetz wrote:
>> 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"?
--
Regards,
J?rg.
J?rg-Volker Peetz wrote on 05/20/2015 10:48:
<snip>
> 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?
--
Regards,
J?rg.