From: Chris Mason <chris.mason@oracle.com>
To: C Anthony Risinger <anthony@extof.me>
Cc: daniel@debian.org, linux-btrfs@vger.kernel.org,
Roger Leigh <rleigh@debian.org>
Subject: Re: Atomic replacement of subvolumes is not possible
Date: Wed, 30 Jun 2010 09:31:42 -0400 [thread overview]
Message-ID: <20100630133142.GU1993@think> (raw)
In-Reply-To: <AANLkTinQmObagOuslcRzuuLZe3ViamIs8e-Jgt-bjRvD@mail.gmail.com>
On Sun, Jun 27, 2010 at 07:44:12PM -0500, C Anthony Risinger wrote:
> On Sat, Jun 26, 2010 at 12:25 PM, Daniel Baumann <daniel@debian.org> =
wrote:
> > Hi,
> >
> > this is basically a forward from
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D587253
> >
> > "rename(2) allows for the atomic replacement of files. =A0Being abl=
e to
> > atomically replace subvolume snapshots would be equally invaluable,
> > since it would permit lock-free replacement of subvolumes.
> >
> > =A0% btrfs subvolume snapshot <src> <dest>
> >
> > creates dest as a snapshot of src. However, if I want to do the
> > converse,
> >
> > =A0% btrfs subvolume snapshot <dest> <src>
> >
> > then <dest> is snapshotted as <src>/<dest>, i.e. not replacing the
> > original subvolume, but going inside the original subvolume.
> >
> > Use case 1:
> > =A0I have a subvolume of data under active use, which I want to
> > =A0periodically update. =A0I'd like to do this by atomically
> > =A0replacing its contents. =A0I can replace the content right now
> > =A0by deleting the old subvolume and then snapshotting the new
> > =A0on in its place, but it's racy. =A0It really needs to be
> > =A0replaced in a single operation, or else there's a small window
> > =A0where there is no data, and I'd need to resort to some external
> > =A0locking to protect myself.
I'm not sure I understand use case #1. The problem is that you'll have
files open in the subvolume and you can't just pull the rug out from
under them. Could you tell me a little more about what you're trying t=
o
do?
> >
> > Use case 2:
> > =A0In schroot, we create btrfs subvolume snapshots to get copy-on-
> > =A0write chroots. =A0This works just fine. =A0We also provide direc=
t
> > =A0access to the "source" subvolume, but since it could be
> > =A0snapshotted in an inconsistent state while being updated, we
> > =A0want to do the following:
> >
> > =A0=B7 snapshot source subvolume
> > =A0=B7 update snapshot
> > =A0=B7 replace source volume with updated snapshot"
> >
> > Please keep roger in the cc for any replies, thanks.
>=20
> i am also looking for functionality similar to this, except i would
> like to be able to replace the DEFAULT subvolume, with an empty or
> existing subvolume, and put the original default subvolume INSIDE the
> new root (or drop it completely), outlined by this post and the threa=
d
> it's in:
>=20
> http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg05278.html
>=20
> is there any feedback on these actions? no one seems to even respond=
:-(
>=20
> it would seem we need ways to swap subvolumes around, _including_ the
> default, providing the on-disk format supports such operations.
Moving 'default' generally involves a reboot for the same reasons. We
have to worry about open files and their view of the filesystem. mv on
a directory won't affect file handles that are open, and renaming
subvolumes needs to follow a similar model.
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-06-30 13:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-26 17:25 Atomic replacement of subvolumes is not possible Daniel Baumann
2010-06-28 0:44 ` C Anthony Risinger
2010-06-30 13:31 ` Chris Mason [this message]
2010-06-30 14:26 ` C Anthony Risinger
2010-07-02 1:30 ` Chris Mason
2010-07-02 16:26 ` C Anthony Risinger
2010-07-02 19:38 ` Goffredo Baroncelli
2010-07-03 15:19 ` C Anthony Risinger
2010-07-02 21:39 ` Bug#587253: " Roger Leigh
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=20100630133142.GU1993@think \
--to=chris.mason@oracle.com \
--cc=anthony@extof.me \
--cc=daniel@debian.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=rleigh@debian.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).