linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 0/3] E2fsprogs: tune2fs: use an ioctl to update mounted fs
Date: Thu, 18 Sep 2025 12:55:32 -0400	[thread overview]
Message-ID: <20250918165532.GC416742@mit.edu> (raw)
In-Reply-To: <C2130E9A-7467-4AC6-A0FE-0C4F4093DE20@dilger.ca>

On Wed, Sep 17, 2025 at 12:26:18AM -0600, Andreas Dilger wrote:
> On Sep 16, 2025, at 21:28, Theodore Ts'o <tytso@mit.edu> wrote:
> > 
> > Teach tune2fs to try use the new EXT4_IOC_SET_TUNE_SB_PARAM ioctl
> > interface to update mounted file systems.  This will allow us to
> > disallow read/write access to the block device while the file system
> > is mounted, once we are sure the updated e2fsprogs is in use.
> 
> Have you considered to use a mount option (eg. mount.ext4) or a flag
> stored in the sb to indicate that a new e2fsprogs is installed in
> userspace?

For better or for worse, currently whether writes to mounted block
devices are blocked is a global switch, controlled by the
bdev_allow_write_mounted boot command-line option and
CONFIG_BLK_DEV_WRITE_MOUNTED (which controls the default).  That's
because it was designed solely to reduce syzbot noise.

As far as I know, ext2 and ext4 are the only file sysetms which
require sysadmins to need write access to mounted file systems (for
tune2fs).  Most other file systems don't actually allow mounted file
system reconfiguration, or they have ioctl's to allow this.  So I
believe that if a system has a newer version of e2fsprogs, it should
be sufficient for the sysadmin to include
bdev_allow_write_mounted=false in the boot options.  (Or for a
distribution to set CONFIG_BLK_DEV_WRITE_MOUNTED if they can guarantee
that a sufficiently new version of e2fsprogs will be installed with a
particular kernel.)

I don't object to having a per-file sytstem mount option, but it would
require changes in block/bdev.c.  And it might involve more complexity
that would be exposed to the system adinistrators.  So unless there is
some other file system type beyond ext4 which might need write access
while the file system is mounetd, maybe we don't need a per-fs switch.
Maybe ext2, but I think most distributions are using
CONFIG_EXT4_USE_FOR_EXT2 so in practice I don't think it's necessary.

Cheers,

						- Ted

      reply	other threads:[~2025-09-18 16:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-17  3:28 [PATCH 0/3] E2fsprogs: tune2fs: use an ioctl to update mounted fs Theodore Ts'o
2025-09-17  3:28 ` [PATCH 1/3] tune2fs: reorganize command-line flag handling Theodore Ts'o
2025-09-17  3:28 ` [PATCH 2/3] tune2fs: rework parse_extended_opts() so it only parses the option string Theodore Ts'o
2025-09-17  6:15   ` Andreas Dilger
2025-09-17  3:28 ` [PATCH 3/3] tune2fs: try to use the SET_TUNE_SB_PARAM ioctl on mounted file systems Theodore Ts'o
2025-09-18 17:47   ` Darrick J. Wong
2025-09-19 15:01     ` Theodore Ts'o
2025-09-17  6:26 ` [PATCH 0/3] E2fsprogs: tune2fs: use an ioctl to update mounted fs Andreas Dilger
2025-09-18 16:55   ` Theodore Ts'o [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=20250918165532.GC416742@mit.edu \
    --to=tytso@mit.edu \
    --cc=adilger@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    /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).