Linux XFS filesystem development
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Carlos Maiolino <cem@kernel.org>,
	linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org,
	Oleksandr Natalenko <oleksandr@natalenko.name>,
	Pavel Reichl <preichl@redhat.com>,
	Thorsten Leemhuis <linux@leemhuis.info>
Subject: Re: [PATCH v2 3/3] xfs: quietly ignore deprecated mount options
Date: Wed, 15 Oct 2025 08:37:02 -0700	[thread overview]
Message-ID: <20251015153702.GY6188@frogsfrogsfrogs> (raw)
In-Reply-To: <93c2e9a0-f374-4211-b4a0-06c716e7d950@suse.cz>

On Wed, Oct 15, 2025 at 10:07:54AM +0200, Vlastimil Babka wrote:
> On 10/15/25 07:04, Darrick J. Wong wrote:
> >  static const struct fs_parameter_spec xfs_fs_parameters[] = {
> > +	/*
> > +	 * These mount options were supposed to be deprecated in September 2025
> > +	 * but the deprecation warning was buggy, so not all users were
> > +	 * notified.  The deprecation is now obnoxiously loud and postponed to
> > +	 * September 2030.
> > +	 */
> 
> FWIW, this seems at odds with the subject "quietly ignore" ;)
> "loudly ignore"? ;)
> "warn about but otherwise ignore"?

Ugh, yeah, I forgot to update the subject line.

"xfs: loudly complain about defunct mount options", then.

> Also there's maybe a difference of ignoring "attr2" because it's enabled
> anyway, and ignoring "noattr2" because it's going to be enabled regardless.
> AFAIK prior to b9a176e54162f8 "noattr2" still prevented the enabling? But
> maybe it's not important. (I don't know how (no)ikeep works.)

Old filesystems will be automatically upgraded to attr2 the next time
anyone writes to an xattr structure.  After V4 is removed in 2030, xfs
won't have to deal with attr1 structures anymore, because V5 always has
attr2.

noikeep was (and still is) the default; it means that inode blocks are
deleted when they are no longer in use.

> Hypothetically someone might complaing after taking a disk out of very old
> system without attr2, booting it on 6.18 that will enable attr2, and not
> being able to use it again in the old system. (Funnily enough similar issue
> recently happened to me with btrfs from Turris 1.0 router's microSD). But
> maybe there are other things besides attr2 that can cause it anyway.
> 
> Anyway I think even in 2030 it will be the best to just keep warning instead
> of refusing to mount.

I think you're right, we should keep this forever.  It's not that big of
a deal to accumulate all the dead mount options via fsparam_dead, and
probably a good tombstone to prevent accidental reuse in the future.

--D

> > +	fsparam_dead("attr2"),
> > +	fsparam_dead("noattr2"),
> > +	fsparam_dead("ikeep"),
> > +	fsparam_dead("noikeep"),
> > +
> >  	fsparam_u32("logbufs",		Opt_logbufs),
> >  	fsparam_string("logbsize",	Opt_logbsize),
> >  	fsparam_string("logdev",	Opt_logdev),
> > @@ -1417,6 +1431,9 @@ xfs_fs_parse_param(
> >  		return opt;
> >  
> >  	switch (opt) {
> > +	case Op_deprecated:
> > +		xfs_fs_warn_deprecated(fc, param);
> > +		return 0;
> >  	case Opt_logbufs:
> >  		parsing_mp->m_logbufs = result.uint_32;
> >  		return 0;
> > @@ -1537,7 +1554,6 @@ xfs_fs_parse_param(
> >  		xfs_mount_set_dax_mode(parsing_mp, result.uint_32);
> >  		return 0;
> >  #endif
> > -	/* Following mount options will be removed in September 2025 */
> >  	case Opt_max_open_zones:
> >  		parsing_mp->m_max_open_zones = result.uint_32;
> >  		return 0;
> 
> 

  reply	other threads:[~2025-10-15 15:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-15  5:01 [PATCH v2 1/3] xfs: don't set bt_nr_sectors to a negative number Darrick J. Wong
2025-10-15  5:03 ` [PATCH v2 2/3] xfs: always warn about deprecated mount options Darrick J. Wong
2025-10-15  5:04 ` [PATCH v2 3/3] xfs: quietly ignore " Darrick J. Wong
2025-10-15  8:07   ` Vlastimil Babka
2025-10-15 15:37     ` Darrick J. Wong [this message]
2025-10-17  5:45       ` Christoph Hellwig
2025-10-17  5:46   ` Christoph Hellwig
2025-10-16 16:25 ` [PATCH 4/3] xfs: fix locking in xchk_nlinks_collect_dir Darrick J. Wong
2025-10-17  5:48   ` Christoph Hellwig
2025-10-21 17:57     ` Darrick J. Wong

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=20251015153702.GY6188@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=cem@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=linux@leemhuis.info \
    --cc=oleksandr@natalenko.name \
    --cc=preichl@redhat.com \
    --cc=vbabka@suse.cz \
    /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