All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Baokun Li <libaokun@linux.alibaba.com>
Cc: linux-ext4@vger.kernel.org, tytso@mit.edu,
	adilger.kernel@dilger.ca, jack@suse.cz, yi.zhang@huawei.com,
	ojaswin@linux.ibm.com, ritesh.list@gmail.com,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH e2fsprogs] tune2fs: touch the device node after setting the label via ioctl
Date: Wed, 23 Sep 2026 10:13:57 -0700	[thread overview]
Message-ID: <20260923171357.GD6239@frogsfrogsfrogs> (raw)
In-Reply-To: <20260923132223.3355764-1-libaokun@linux.alibaba.com>

[cc linux-fsdevel]

On Wed, Sep 23, 2026 at 09:22:23PM +0800, Baokun Li wrote:
> When the file system is mounted, tune2fs sets the label through
> FS_IOC_SETFSLABEL, which updates the label without touching the
> mtime of the device node.  Consumers such as blkid use that mtime
> to validate their cached superblock information, so the old label
> can still be returned right after the change:
> 
>   blkid -s LABEL /dev/sdb    # gets "old" and caches it
>   tune2fs -L new /dev/sdb    # online path, node mtime unchanged
>   blkid -s LABEL /dev/sdb    # still gets "old" within 2s
> 
> The offline path is unaffected because writing the superblock
> through the device node updates its mtime as a side effect.  The
> ioctl path has no such side effect, so add an explicit utime() on
> the device after a successful FS_IOC_SETFSLABEL.
> 
> The return value is ignored; if the touch fails, the behavior is
> no worse than before.
> 
> Suggested-by: Theodore Ts'o <tytso@mit.edu>
> Link: https://patch.msgid.link/arKZu30pMe0ZavVA@mit.edu
> Signed-off-by: Baokun Li <libaokun@linux.alibaba.com>
> ---
>  misc/tune2fs.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/misc/tune2fs.c b/misc/tune2fs.c
> index 2d85fb704e15..87b8e6830bb9 100644
> --- a/misc/tune2fs.c
> +++ b/misc/tune2fs.c
> @@ -48,6 +48,7 @@ extern int optind;
>  #endif
>  #include <string.h>
>  #include <time.h>
> +#include <utime.h>
>  #include <unistd.h>
>  #include <sys/types.h>
>  #include <libgen.h>
> @@ -3167,6 +3168,14 @@ static int handle_fslabel(int setlabel)
>  		return 1;
>  	}
>  	close(fd);
> +
> +	/*
> +	 * FS_IOC_SETFSLABEL does not touch the device mtime that
> +	 * blkid uses to validate its cache; touch the device so
> +	 * mtime-based consumers see the change.
> +	 */
> +	utime(device_name, NULL);

For everyone on fsdevel who might be seeing this for the first time,
there was a problem report in which it was discovered that the libblkid
cache invalidates its knowledge if something updates the block device
mtime.  This is done whenever userspace tools update a block device
(e.g. mkfs) but not done by the kernel when it rewrites the primary
superblock (e.g. FS_IOC_SETFSLABEL).

This patch fixes tune2fs to add the missing mtime update, but I think
a better way to solve this is to fix the ~8 or so implementations inside
the kernel.  And maybe the FS_IOC_SETFSUUID implementations too.

A bigger question, then, is whether filesystems should bump mtime /any/
time they update their own superblock?  There aren't any published specs
mandating this behavior by the kernel, but I suppose it falls under
"someone observed a behavior and started relying on it" :P

Thoughts?

--D

[1] https://lore.kernel.org/linux-ext4/20260920094137.2749428-1-libaokun@linux.alibaba.com/

> +
>  	return 0;
>  #else
>  	return -1;
> -- 
> 2.43.7
> 
> 

      reply	other threads:[~2026-09-23 17:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-23 13:22 [PATCH e2fsprogs] tune2fs: touch the device node after setting the label via ioctl Baokun Li
2026-09-23 17:13 ` Darrick J. Wong [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=20260923171357.GD6239@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=adilger.kernel@dilger.ca \
    --cc=jack@suse.cz \
    --cc=libaokun@linux.alibaba.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=ojaswin@linux.ibm.com \
    --cc=ritesh.list@gmail.com \
    --cc=tytso@mit.edu \
    --cc=yi.zhang@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.