i switched from "noatime,nodiratime" to "relatime,nodiratime,lazytime" which seems to lead in unexpected mtime changes for a lot of files leading in rkhunter alerts and likely rsync problems
May 15 13:35:51 Installed: kernel-core-4.0.3-201.fc21.x86_64 May 15 13:35:54 Installed: kernel-modules-4.0.3-201.fc21.x86_64 May 15 13:35:55 Updated: kernel-headers-4.0.3-201.fc21.x86_64
Warning: Package manager verification has failed: File: /usr/bin/vmstat The file modification time has changed Warning: Package manager verification has failed: File: /usr/sbin/fsck The file modification time has changed Warning: Package manager verification has failed: File: /usr/sbin/nologin The file modification time has changed
[root@rh:~]$ stat /usr/sbin/fsck File: '/usr/sbin/fsck' Size: 37168 Blocks: 80 IO Block: 4096 regular file Device: 901h/2305d Inode: 1309455 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-05-18 11:30:07.909951123 +0200 Modify: 2015-05-15 13:34:47.037194874 +0200 Change: 2015-05-15 13:34:47.037194874 +0200
On 5/19/15 4:14 AM, Reindl Harald wrote:
i switched from "noatime,nodiratime" to "relatime,nodiratime,lazytime" which seems to lead in unexpected mtime changes for a lot of files leading in rkhunter alerts and likely rsync problems
The cargo-cult tuning, it burns! ;)
noatime implies nodiratime, no need to specify both:
touch_atime() { ... if (mnt->mnt_flags & MNT_NOATIME) return; if ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode)) return;
and relatime is default, so no need to re-specify:
/* Default to relatime unless overriden */ if (!(flags & MS_NOATIME)) mnt_flags |= MNT_RELATIME;
Anyway ... you didn't say what kernel you were running under, or what filesystem.
If it's ext4, there have been some flaws there; recently:
commit 8f4d855839179f410fa910a26eb81d646d628f26 Author: Theodore Ts'o tytso@mit.edu Date: Thu May 14 18:19:01 2015 -0400
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>
which looks like it's probably the culprit. This was broken since:
commit a26f49926da938f47561f386be56a83dd37a496d Author: Theodore Ts'o tytso@mit.edu Date: Mon Feb 2 00:37:02 2015 -0500
ext4: add optimization for the lazytime mount option
in v4.0-rc1
-Eric
May 15 13:35:51 Installed: kernel-core-4.0.3-201.fc21.x86_64 May 15 13:35:54 Installed: kernel-modules-4.0.3-201.fc21.x86_64 May 15 13:35:55 Updated: kernel-headers-4.0.3-201.fc21.x86_64
Warning: Package manager verification has failed: File: /usr/bin/vmstat The file modification time has changed Warning: Package manager verification has failed: File: /usr/sbin/fsck The file modification time has changed Warning: Package manager verification has failed: File: /usr/sbin/nologin The file modification time has changed
[root@rh:~]$ stat /usr/sbin/fsck File: '/usr/sbin/fsck' Size: 37168 Blocks: 80 IO Block: 4096 regular file Device: 901h/2305d Inode: 1309455 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2015-05-18 11:30:07.909951123 +0200 Modify: 2015-05-15 13:34:47.037194874 +0200 Change: 2015-05-15 13:34:47.037194874 +0200
kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Am 19.05.2015 um 17:25 schrieb Eric Sandeen:
On 5/19/15 4:14 AM, Reindl Harald wrote:
i switched from "noatime,nodiratime" to "relatime,nodiratime,lazytime" which seems to lead in unexpected mtime changes for a lot of files leading in rkhunter alerts and likely rsync problems
The cargo-cult tuning, it burns! ;)
noatime implies nodiratime, no need to specify both:
and "relatime" implies it too?
touch_atime() { ... if (mnt->mnt_flags & MNT_NOATIME) return; if ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode)) return;
different story
and relatime is default, so no need to re-specify:
/* Default to relatime unless overriden */ if (!(flags & MS_NOATIME)) mnt_flags |= MNT_RELATIME;Anyway ... you didn't say what kernel you were running under, or what filesystem.
surely you just stripped that part from your reply
May 15 13:35:51 Installed: kernel-core-4.0.3-201.fc21.x86_64 May 15 13:35:54 Installed: kernel-modules-4.0.3-201.fc21.x86_64 May 15 13:35:55 Updated: kernel-headers-4.0.3-201.fc21.x86_64
If it's ext4, there have been some flaws there; recently:
yes, "lazytime" implies ext4
commit 8f4d855839179f410fa910a26eb81d646d628f26 Author: Theodore Ts'o tytso@mit.edu Date: Thu May 14 18:19:01 2015 -0400
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>which looks like it's probably the culprit. This was broken since:
commit a26f49926da938f47561f386be56a83dd37a496d Author: Theodore Ts'o tytso@mit.edu Date: Mon Feb 2 00:37:02 2015 -0500
ext4: add optimization for the lazytime mount option
wow - and nobody noticed all the months that mtimes are randomly changing all over the system while it takes exactly one day to get rkhunter mails and rsync listing a ton of untouched files
On Tue, May 19, 2015 at 11:46 AM, Reindl Harald h.reindl@thelounge.net wrote:
commit 8f4d855839179f410fa910a26eb81d646d628f26 Author: Theodore Ts'o tytso@mit.edu Date: Thu May 14 18:19:01 2015 -0400
ext4: fix lazytime optimization We had a fencepost error in the lazytime optimization which meansthat timestamp would get written to the wrong inode.
Cc: stable@vger.kernel.org Signed-off-by: Theodore Ts'o <tytso@mit.edu>which looks like it's probably the culprit. This was broken since:
commit a26f49926da938f47561f386be56a83dd37a496d Author: Theodore Ts'o tytso@mit.edu Date: Mon Feb 2 00:37:02 2015 -0500
ext4: add optimization for the lazytime mount optionwow - and nobody noticed all the months that mtimes are randomly changing all over the system while it takes exactly one day to get rkhunter mails and rsync listing a ton of untouched files
That isn't really all that surprising. The lazytime mount option is very new, isn't used by default anywhere, and likely isn't widely tested outside of the usecase the original developers had in mind.
josh
On 5/19/15 10:46 AM, Reindl Harald wrote:
Am 19.05.2015 um 17:25 schrieb Eric Sandeen:
On 5/19/15 4:14 AM, Reindl Harald wrote:
i switched from "noatime,nodiratime" to "relatime,nodiratime,lazytime" which seems to lead in unexpected mtime changes for a lot of files leading in rkhunter alerts and likely rsync problems
The cargo-cult tuning, it burns! ;)
noatime implies nodiratime, no need to specify both:
and "relatime" implies it too?
Nope, relatime is relatime. ;)
The no[dir]atime options disable atime updates completely; relatime acts as documented in mount(8), opportunistically updating atime when it's more efficient to do so, and skipping it other times.
touch_atime() { ... if (mnt->mnt_flags & MNT_NOATIME) return; if ((mnt->mnt_flags & MNT_NODIRATIME) && S_ISDIR(inode->i_mode)) return;
different story
I simply mean that if you have set noatime, you never even get to the nodiratime test; hence noatime,nodiratime is redundant.
and relatime is default, so no need to re-specify:
/* Default to relatime unless overriden */ if (!(flags & MS_NOATIME)) mnt_flags |= MNT_RELATIME;Anyway ... you didn't say what kernel you were running under, or what filesystem.
surely you just stripped that part from your reply
May 15 13:35:51 Installed: kernel-core-4.0.3-201.fc21.x86_64 May 15 13:35:54 Installed: kernel-modules-4.0.3-201.fc21.x86_64 May 15 13:35:55 Updated: kernel-headers-4.0.3-201.fc21.x86_64
You were installing that kernel, but I didn't know what kernel was running when you installed those packages. :)
If it's ext4, there have been some flaws there; recently:
yes, "lazytime" implies ext4
Oh, I guess so, I forgot this was another ext4-only special hack, sorry.
commit 8f4d855839179f410fa910a26eb81d646d628f26 Author: Theodore Ts'o tytso@mit.edu Date: Thu May 14 18:19:01 2015 -0400
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>which looks like it's probably the culprit. This was broken since:
commit a26f49926da938f47561f386be56a83dd37a496d Author: Theodore Ts'o tytso@mit.edu Date: Mon Feb 2 00:37:02 2015 -0500
ext4: add optimization for the lazytime mount optionwow - and nobody noticed all the months that mtimes are randomly changing all over the system while it takes exactly one day to get rkhunter mails and rsync listing a ton of untouched files
Apparently not. :)
-Eric
kernel@lists.fedoraproject.org
-
Eric Sandeen -
Josh Boyer -
Reindl Harald