From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: Eric Sandeen <sandeen@redhat.com>,
linux-xfs <linux-xfs@vger.kernel.org>,
"Darrick J. Wong" <darrick.wong@oracle.com>
Subject: Re: [PATCH] xfs_admin: revert online label setting ability
Date: Mon, 2 Mar 2020 14:10:23 +1100 [thread overview]
Message-ID: <20200302031023.GI10776@dread.disaster.area> (raw)
In-Reply-To: <3d7b7a5c-c1bf-1fc9-686e-707165181d07@sandeen.net>
On Sun, Mar 01, 2020 at 03:13:07PM -0600, Eric Sandeen wrote:
> On 3/1/20 12:55 PM, Dave Chinner wrote:
> > On Sun, Mar 01, 2020 at 09:50:03AM -0800, Eric Sandeen wrote:
> >> The changes to xfs_admin which allowed online label setting via
> >> ioctl had some unintended consequences in terms of changing command
> >> order and processing. It's going to be somewhat tricky to fix, so
> >> back it out for now.
> >
> > What are the symptoms and behaviour of these "unintended
> > consequences"? And why are they tricky to fix?
>
> Yeah, I should have probably said more in the commit log.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=206429
>
> was the first clue,
>
> "xfs_admin can't print both label and UUID for mounted filesystems"
>
> The main problem is that if /any/ options that trigger xfs_io get specified,
> they are the only ones that get run:
>
> # Try making the changes online, if supported
> if [ -n "$IO_OPTS" ] && mntpt="$(find_mntpt_for_arg "$1")"
> then
> eval xfs_io -x -p xfs_admin $IO_OPTS "$mntpt"
> test "$?" -eq 0 && exit 0
> fi
>
> and the non-io / db opts don't get run at all.
>
> So sure, we could then move on to the db commands, but we actually built them
> all up along the way as well:
>
> l) DB_OPTS=$DB_OPTS" -r -c label"
> IO_OPTS=$IO_OPTS" -r -c label"
> ;;
>
> so we'd need to keep those separate, and not re-run them in db.
>
> And another thing that I struggled with was preserving the order; you'd
> kind of expect that if you specify commands in a certain order
> they'd be executed in that order, and that used to be true. Now it's not,
> even if we don't exit in the "if IO_OPTS" case above.
>
> So I experimented with building up an array of commands, invoking xfs_db
> or xfs_io one command at a time as needed for each, and ... it just got worse
> and worse, TBH.
And there's your new commit message. :)
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2020-03-02 3:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-01 17:50 [PATCH] xfs_admin: revert online label setting ability Eric Sandeen
2020-03-01 20:55 ` Dave Chinner
2020-03-01 21:13 ` Eric Sandeen
2020-03-02 3:10 ` Dave Chinner [this message]
2020-03-02 14:35 ` [PATCH V2] " Eric Sandeen
2020-03-03 1:18 ` 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=20200302031023.GI10776@dread.disaster.area \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@redhat.com \
--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 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.