From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Sheena Artrip <sheena.artrip@gmail.com>
Cc: Dave Chinner <david@fromorbit.com>,
Eric Sandeen <sandeen@sandeen.net>,
Sheena Artrip <sheenobu@fb.com>,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH v2] xfs_restore: detect rtinherit on destination
Date: Mon, 17 Jun 2019 15:55:58 -0700 [thread overview]
Message-ID: <20190617225558.GN3773859@magnolia> (raw)
In-Reply-To: <CABeZSNkGoKhfV2-=CfqSPUsf9CxLNFP5vRa161M_LowfnJ8TzA@mail.gmail.com>
On Mon, Jun 17, 2019 at 03:09:15PM -0700, Sheena Artrip wrote:
> On Thu, Jun 6, 2019 at 3:37 PM Dave Chinner <david@fromorbit.com> wrote:
> >
> > On Thu, Jun 06, 2019 at 05:08:12PM -0500, Eric Sandeen wrote:
> > > On 6/6/19 4:50 PM, Dave Chinner wrote:
> > > > My take on this is that we need to decide which allocation policy to
> > > > use - the kernel policy or the dump file policy - in the different
> > > > situations. It's a simple, easy to document and understand solution.
> > > >
> > > > At minimum, if there's a mismatch between rtdev/non-rtdev between
> > > > dump and restore, then restore should not try to restore or clear rt
> > > > flags at all. i.e the rt flags in the dump image should be
> > > > considered invalid in this situation and masked out in the restore
> > > > process. This prevents errors from being reported during restore,
> > > > and it does "the right thing" according to how the user has
> > > > configured the destination directory. i.e. if the destdir has the
> > > > rtinherit bit set and there's a rtdev present, the kernel policy
> > > > will cause all file data that is restored to be allocated on the
> > > > rtdev. Otherwise the kernel will place it (correctly) on the data
> > > > dev.
> > > >
> > > > In the case where both have rtdevs, but you want to restore to
> > > > ignore the dump file rtdev policy, we really only need to add a CLI
> > > > option to say "ignore rt flags" and that then allows the kernel
> > > > policy to dictate how the restored files are placed in the same way
> > > > that having a rtdev mismatch does.
> > > >
> > > > This is simple, consistent, fulfils the requirements and should have
> > > > no hidden surprises for users....
> > >
> > > Sounds reasonable. So the CLI flag would say "ignore RT info in the
> > > dump, and write files according to the destination fs policy?"
> > > I think that makes sense.
>
> Any suggested flag name/prefix for this? Last i checked all the single
> letters were taken up?
I suggest --preserve-xflags=<same letters as xfs_io lsattr command>
--D
> > *nod*
> >
> > > Now: do we need to do the same for all inheritable flags? projid,
> > > extsize, etc? I think we probably do.
> >
> > I disagree. These things are all supported on all destination
> > filesystems, unlike the rtdev. They are also things that can be
> > changed after the fact, unlike rtdev allocation policy. i.e. rtdev
> > has to be set /before/ restore, just about everything else can be
> > set or reset after the fact....
> > Cheers,
> >
> > Dave.
> > --
> > Dave Chinner
> > david@fromorbit.com
next prev parent reply other threads:[~2019-06-17 22:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-05 21:16 [RFC][PATCH] xfs_restore: detect rtinherit on destination Sheena Artrip
2019-06-06 14:11 ` Eric Sandeen
2019-06-06 18:12 ` Sheena Artrip
2019-06-06 18:39 ` Eric Sandeen
2019-06-06 19:50 ` Sheena Artrip
2019-06-06 19:57 ` [PATCH v2] " Sheena Artrip
2019-06-06 21:23 ` Eric Sandeen
2019-06-06 21:50 ` Dave Chinner
2019-06-06 22:08 ` Eric Sandeen
2019-06-06 22:36 ` Dave Chinner
2019-06-17 22:09 ` Sheena Artrip
2019-06-17 22:55 ` Darrick J. Wong [this message]
2019-06-18 6:28 ` Sheena Artrip
2019-06-18 15:09 ` 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=20190617225558.GN3773859@magnolia \
--to=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
--cc=sheena.artrip@gmail.com \
--cc=sheenobu@fb.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.