linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Chris Dunlop <chris@onthe.net.au>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [RFD] XFS: Subvolumes and snapshots....
Date: Tue, 24 Aug 2021 09:12:35 +1000	[thread overview]
Message-ID: <20210823231235.GK3657114@dread.disaster.area> (raw)
In-Reply-To: <20210823045701.GA2186939@onthe.net.au>

On Mon, Aug 23, 2021 at 02:57:01PM +1000, Chris Dunlop wrote:
> Hi,
> 
> On Thu, Jan 25, 2018 at 04:51:44PM +1100, Dave Chinner wrote:
> > The video from my talk at LCA 2018 yesterday about the XFS subvolume and
> > snapshot support I'm working on has been uploaded and can be found
> > here:
> > 
> > https://www.youtube.com/watch?v=wG8FUvSGROw
> 
> Just out of curiosity... is anything still happening in this area, and if
> so, is there anywhere we can look to get a feel for the current state of
> affairs?

It's at the back of the queue at the moment. There's not enough
time and resources available to do everything we want to do - just
look at the review backlog we already have...

That said, this was largely an experiment to see how easily we could
retrofit subvolumes to XFS, and whether there was a compelling
reason for adding them. While there are some management benefits to
integrating reflink based subvolumes into XFS, the performance and
scalability just isn't there compared to production usage of things
like dm-snapshot.

O(1) snapshot time makes a huge difference to system performance,
but reflink-based snapshots are O(N), not O(1). Hence snapshots run
at about 100k extents/sec so a subvolume with a few million extents
will take 10s of seconds to run a snapshot. During this time, the
subvolume is completely frozen and you can't read from or write to
it....

And that's really the unsolvable problem with a reflink based
snapshot mechanism. Unless there is some other versioning mechanism
in the filesystem metadata, we have to mark all the extents in the
subvolume as shared so the next write will COW them correctly. XFS
does not have that "some other mechanism" like btrfs (COW metadata)
or bcachefs (snapshot epoch in btree keys), so it will never be able
to solve this problem effectively.

That's not to say we'll never add subvolumes and snapshots to XFS,
but because it isn't compellingly better than existing mechanisms
for snapshotting XFS filesystems it really isn't a priority.

As such, if you want a performant, scalable, robust snapshotting
subvolume capable filesystem, bcachefs is the direction you should
be looking. All of the benefits of integrated subvolume snapshots,
yet none of the fundamental architectural deficiencies and design
flaws that limit the practical usability of btrfs for many important
workloads.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

      reply	other threads:[~2021-08-23 23:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-25  5:51 [RFD] XFS: Subvolumes and snapshots Dave Chinner
2018-01-27  8:34 ` Amir Goldstein
2018-01-27 11:28   ` Dave Chinner
2018-01-27 15:56     ` Amir Goldstein
2018-01-28  1:57       ` Dave Chinner
2018-01-27 17:05 ` Martin Raiber
2018-01-28  1:59   ` Dave Chinner
2018-01-28 12:59 ` Martin Steigerwald
2018-01-29  1:50   ` Dave Chinner
2021-08-23  4:57 ` Chris Dunlop
2021-08-23 23:12   ` 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=20210823231235.GK3657114@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=chris@onthe.net.au \
    --cc=linux-xfs@vger.kernel.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 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).