From: "Darrick J. Wong" <djwong@kernel.org>
To: Geert Hendrickx <geert@hendrickx.be>
Cc: Eric Sandeen <sandeen@sandeen.net>, xfs <linux-xfs@vger.kernel.org>
Subject: Re: xfs_admin -O feature upgrade feedback
Date: Mon, 1 Mar 2021 11:18:03 -0800 [thread overview]
Message-ID: <20210301191803.GE7269@magnolia> (raw)
In-Reply-To: <YDy+OmsVCkTfiMPp@vera.ghen.be>
[adding linux-xfs to cc]
On Mon, Mar 01, 2021 at 11:13:14AM +0100, Geert Hendrickx wrote:
> Gentlemen
>
>
> I've been testing xfsprogs 5.11.0-rc1 for XFS feature upgrades (inobtcount
> and bigtime), and have a couple of small nits with it - besides the actual
> functionality working as expected:
>
> 1/ xfs_admin responds to every xfs_repair failure with the very generic
> "Conversion failed, is the filesystem unmounted?" This isn't very helpful
> (and left me scratching my head in a number of scenarios), whereas calling
> xfs_repair directly shows a relevant error message in all cases. This
> output should somehow be relayed through xfs_admin - without just dumping
> the whole xfs_repair output which I know you wanted to avoid. Maybe by
> distinguishing more carefully between stderr and stdout? (Currently, it
> seems xfs_repair sends its errors to stdout and "normal output" to stderr,
> and xfs_admin discards xfs_repair's stderr.)
That's a difficult project -- some of the things repair will complain
about are a result of whatever the upgrade is (e.g. complaining about
incorrect inode btree counters when you're in the process of enabling
the counters) but then there are other things that it probably should
not be dropping on the floor.
> 2/ minor, but xfs_admin(8) manpage documents `xfs_admin -O feature=status`,
> however xfs_admin itself appends another `=1`, resulting in `xfs_repair -c
> feature=1=1`. This works, but looks ugly, and is not consistent with the
> option to enable multiple features at once. I think either the xfs_admin
> script or its manpage should be adjusted to be consistent?
Yeah, xfs_admin should not add '=1'. Thanks for pointing that out.
> Apart from this, the actual upgrade functionality is working as expected,
> great job!
Thx :)
> Btw, do you have an idea from which release onwards mkfs.xfs will enable
> the new features by default? Are there fixed rules for this (like feature
> must be X releases old, or supported by the latest LTS kernel), or is this
> judged on a case-by-case basis?
~6mo after we hear that people are using the feature /and/ we haven't
heard of any serious complaints.
Or some distro makes a business case and enables it by default. <cough>
--D
>
> Thanks!
>
>
> Geert
>
>
next parent reply other threads:[~2021-03-01 20:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <YDy+OmsVCkTfiMPp@vera.ghen.be>
2021-03-01 19:18 ` Darrick J. Wong [this message]
2021-03-01 22:31 ` xfs_admin -O feature upgrade feedback Geert Hendrickx
2021-03-02 12:19 ` Brian Foster
2021-03-02 22:57 ` Geert Hendrickx
2021-03-03 11:50 ` Brian Foster
2021-03-03 13:20 ` Geert Hendrickx
2021-03-03 17:00 ` Darrick J. Wong
2021-03-04 2:07 ` Dave Chinner
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=20210301191803.GE7269@magnolia \
--to=djwong@kernel.org \
--cc=geert@hendrickx.be \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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).