| Message ID | 20150514222044.GA3901@thunk.org |
|---|---|
| State | Accepted, archived |
| Headers | show |
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.
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 <tytso@mit.edu> > 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: stable@vger.kernel.org > Signed-off-by: Theodore Ts'o <tytso@mit.edu> > --- > 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; >
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 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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"?
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?
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;