linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Amir Goldstein <amir73il@gmail.com>
Cc: linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [RFD] XFS: Subvolumes and snapshots....
Date: Sun, 28 Jan 2018 12:57:26 +1100	[thread overview]
Message-ID: <20180128015726.czd42ajhqfdqdtnz@destitution> (raw)
In-Reply-To: <CAOQ4uxi-UY1Ak3Ppu7yFux9v4S3BwgbwFYLJdivvc-Vt4REdFg@mail.gmail.com>

On Sat, Jan 27, 2018 at 05:56:53PM +0200, Amir Goldstein wrote:
> On Sat, Jan 27, 2018 at 1:28 PM, Dave Chinner <david@fromorbit.com> wrote:
> > On Sat, Jan 27, 2018 at 10:34:25AM +0200, Amir Goldstein wrote:
> >> On Thu, Jan 25, 2018 at 7:51 AM, Dave Chinner <david@fromorbit.com> 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
> >> >
> >> > I don't have the code in a reviewable form yet - there's still quite
> >> > a bit of work before I get to that point, but this is a good
> >> > introduction to how all the pieces will fit together....
> >> >
> >>
> >> Very cool!
> >>
> >> Got any paper napkin design photo to share?
> >
> > No. I have some arch docs I wrote after the initial Poc on loopback
> > devices and a bunch of bash, sed, awk and xfs_io hacks....
> >
> [...]
> >
> >> I suppose all subvolumes use the host fs journal?
> >
> > No. A subvolume is a "fully functioning filesystem" and so - by
> > definition - they each have their own internal journal. The journal
> > IO remapping and COW functionality all works as seen in that demo...
> 
> So is FUA from subvolume going to be handled the same as with loop
> (fsync of entire image file) or more efficiently? for example by flushing
> only dirty pages that are already mapped?

FUA from the subvoume is mapped directly to the nuderlying device,
just like all other IO. i.e. we never need to "fsync" the underlying
file. We only need to make sure the underlying extent map for the
subvolume is flushed when necessary. This is exactly the same
constraint as the PNFS file layout offload case, handled by the
->commit_metadata() export operation. (i.e
xfs_fs_nfs_commit_metadata()).

(I did mention in the talk that the pNFS model was instructive in
the talk, because it already handles issues like this.... :)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2018-01-28  1:56 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 [this message]
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

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=20180128015726.czd42ajhqfdqdtnz@destitution \
    --to=david@fromorbit.com \
    --cc=amir73il@gmail.com \
    --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).