All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: L A Walsh <xfs@tlinx.org>
Cc: linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: RFD: question/probe regarding adding dump-levels A-Z after 0-9 for xfs{dump,restore}
Date: Tue, 11 Dec 2018 08:55:07 +1100	[thread overview]
Message-ID: <20181210215507.GD6311@dastard> (raw)
In-Reply-To: <5C0A70FD.6080806@tlinx.org>

On Fri, Dec 07, 2018 at 05:09:17AM -0800, L A Walsh wrote:
> How difficult would it be to allow 26 more dump levels
> in xfs dump/restore?  Theoretically anyone using 0-9
> would see no change.  Would there be some "problem" or
> "gotcha" in adding in what would _seem_ to be a simple
> change?

Everything _seems_ simple with xfsdump. e.g. the inventory
session headers supports up to 255 levels in it's on-disk format,
but the xfsdump command is limited to just 10 levels by a separate
"max level" define. 

IOWs, on the surface it _seems_ simple to change it, but I don't
know all the places that the dump level is stored, nor what would
happen if an older xfsdump/xfsrestore binary tripped over an
inventory with a dump level larger than they were compiled to
handle.

I also don't know if there are scalability problems with resolving
the contents of incremental dump levels. Certainly restoring from 30
incremental dumps is more onerous than 6-7, but that's just time.
What I don't know is how the invenetory scales to more than 10
incremental and whether there's some exponential algorithm in there
that falls apart. So there's a lot of testing that would be needed
to validate what looks like a 1 line change to the code.

So, yes, technically we could increase the dump level, but there's a
*lot* of verification work after doing so and it's not a risk-free
modification. 

FWIW, the idea behind 10 dump levels is that it is enough for a
full dump every week w/ an incremental every night of the week until
the next full dump is done on the weekend. What's the backup plan
you want to use/need that requires a larger number of incrementals?
Knowing what you want more dump levels for helps us understand how
it would be used and what really needs to be testedi first....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

      reply	other threads:[~2018-12-10 21:55 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-07 13:09 RFD: question/probe regarding adding dump-levels A-Z after 0-9 for xfs{dump,restore} L A Walsh
2018-12-10 21:55 ` Dave Chinner [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=20181210215507.GD6311@dastard \
    --to=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=xfs@tlinx.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 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.