From: Sean Greenslade <sean@seangreenslade.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Bagas Sanjaya <bagasdotme@gmail.com>,
linux-ext4@vger.kernel.org, Ye Bin <yebin10@huawei.com>,
Thorsten Leemhuis <regressions@leemhuis.info>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Regressions <regressions@lists.linux.dev>
Subject: Re: RO mount of ext4 filesystem causes writes
Date: Fri, 23 Jun 2023 09:53:36 -0700 [thread overview]
Message-ID: <ZJXOEJkCbAb0nG_I@glitch> (raw)
In-Reply-To: <20230623143411.GF34229@mit.edu>
On Fri, Jun 23, 2023 at 10:34:11AM -0400, Theodore Ts'o wrote:
> Ah, yes, your initial report said "small writes", but it didn't
> specify whether the issue was that writes were modifying the image, or
> just simply touching the mtime field of the backing file. I assume
> these must be largish fs images, since it must have made the increased
> rsync time noticeable?
Yeah, these are ~30 GB images on spinning drives, so it's the difference
between near-instant and several minutes.
> This appears to fix the problem for me, given the clarified
> reproduction information. Could you please try it on your end?
>
> - Ted
Yup, this patch does indeed solve the problem I'm seeing. Thanks!
--Sean
> From 6bb438fa0aac4c08acd626d408cb6d4b745df7fd Mon Sep 17 00:00:00 2001
> From: Theodore Ts'o <tytso@mit.edu>
> Date: Fri, 23 Jun 2023 10:18:51 -0400
> Subject: [PATCH] ext4: avoid updating the superblock on a r/o mount if not
> needed
>
> This was noticed by a user who noticied that the mtime of a file
> backing a loopback device was getting bumped when the loopback device
> is mounted read/only. Note: This doesn't show up when doing a
> loopback mount of a file directly, via "mount -o ro /tmp/foo.img
> /mnt", since the loop device is set read-only when mount automatically
> creates loop device. However, this is noticeable for a LUKS loop
> device like this:
>
> % cryptsetup luksOpen /tmp/foo.img test
> % mount -o ro /dev/loop0 /mnt ; umount /mnt
>
> or, if LUKS is not in use, if the user manually creates the loop
> device like this:
>
> % losetup /dev/loop0 /tmp/foo.img
> % mount -o ro /dev/loop0 /mnt ; umount /mnt
>
> The modified mtime causes rsync to do a rolling checksum scan of the
> file on the local and remote side, incrementally increasing the time
> to rsync the not-modified-but-touched image file.
>
> Fixes: eee00237fa5e ("ext4: commit super block if fs record error when journal record without error")
> Cc: stable@kernel.org
> Link: https://lore.kernel.org/r/ZIauBR7YiV3rVAHL@glitch
> Reported-by: Sean Greenslade <sean@seangreenslade.com>
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> ---
> fs/ext4/super.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index b3819e70093e..c638b0db3b2b 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -5997,19 +5997,27 @@ static int ext4_load_journal(struct super_block *sb,
> err = jbd2_journal_wipe(journal, !really_read_only);
> if (!err) {
> char *save = kmalloc(EXT4_S_ERR_LEN, GFP_KERNEL);
> + __le16 orig_state;
> + bool changed = false;
>
> if (save)
> memcpy(save, ((char *) es) +
> EXT4_S_ERR_START, EXT4_S_ERR_LEN);
> err = jbd2_journal_load(journal);
> - if (save)
> + if (save && memcmp(((char *) es) + EXT4_S_ERR_START,
> + save, EXT4_S_ERR_LEN)) {
> memcpy(((char *) es) + EXT4_S_ERR_START,
> save, EXT4_S_ERR_LEN);
> + changed = true;
> + }
> kfree(save);
> + orig_state = es->s_state;
> es->s_state |= cpu_to_le16(EXT4_SB(sb)->s_mount_state &
> EXT4_ERROR_FS);
> + if (orig_state != es->s_state)
> + changed = true;
> /* Write out restored error information to the superblock */
> - if (!bdev_read_only(sb->s_bdev)) {
> + if (changed && !really_read_only) {
> int err2;
> err2 = ext4_commit_super(sb);
> err = err ? : err2;
> --
> 2.31.0
prev parent reply other threads:[~2023-06-23 16:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-12 5:32 RO mount of ext4 filesystem causes writes Sean Greenslade
2023-06-12 6:20 ` Bagas Sanjaya
2023-06-13 4:48 ` Sean Greenslade
2023-06-23 1:06 ` Bagas Sanjaya
2023-06-23 4:46 ` Theodore Ts'o
2023-06-23 6:18 ` Sean Greenslade
2023-06-23 14:34 ` Theodore Ts'o
2023-06-23 15:38 ` Ritesh Harjani
2023-06-24 19:39 ` Theodore Ts'o
2023-06-23 16:53 ` Sean Greenslade [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZJXOEJkCbAb0nG_I@glitch \
--to=sean@seangreenslade.com \
--cc=bagasdotme@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=regressions@leemhuis.info \
--cc=regressions@lists.linux.dev \
--cc=tytso@mit.edu \
--cc=yebin10@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).