linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Thu, 1 Jul 2010 21:30:54 -0400	[thread overview]
Message-ID: <20100702013054.GC15319@think> (raw)
In-Reply-To: <AANLkTilcAfaH4KmSzKGp8M-xj511IlowGgIZnhHopdNx@mail.gmail.com>

On Wed, Jun 30, 2010 at 09:26:11AM -0500, C Anthony Risinger wrote:
> On Wed, Jun 30, 2010 at 8:31 AM, Chris Mason <chris.mason@oracle.com>=
 wrote:
> > 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.or=
g> 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 =
able to
> >> > atomically replace subvolume snapshots would be equally invaluab=
le,
> >> > 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 t=
he
> >> > 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 no=
w
> >> > =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 windo=
w
> >> > =A0where there is no data, and I'd need to resort to some extern=
al
> >> > =A0locking to protect myself.
> >
> > I'm not sure I understand use case #1. =A0The problem is that you'l=
l have
> > files open in the subvolume and you can't just pull the rug out fro=
m
> > under them. =A0Could you tell me a little more about what you're tr=
ying to
> > do?
> >
> >> >
> >> > Use case 2:
> >> > =A0In schroot, we create btrfs subvolume snapshots to get copy-o=
n-
> >> > =A0write chroots. =A0This works just fine. =A0We also provide di=
rect
> >> > =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.
> >>
> >> i am also looking for functionality similar to this, except i woul=
d
> >> 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 th=
read
> >> it's in:
> >>
> >> http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg05278.h=
tml
> >>
> >> is there any feedback on these actions? =A0no one seems to even re=
spond :-(
> >>
> >> 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. =
=A0We
> > have to worry about open files and their view of the filesystem. =A0=
mv on
> > a directory won't affect file handles that are open, and renaming
> > subvolumes needs to follow a similar model.
>=20
> could we fail if the user tries to replace a subvolume while it's
> being used?  what if the root device is _not_ the default (".")
> subvolume, then can it be swapped?
>=20
> in my use case, i am running in initramfs, so the root device has not
> even been mounted or pivoted to; it should be safe to do whatever i
> want to the filesystem.  i want to move the user's installation to a
> dedicated subvolume.
>=20
> what about this:  would it be possible to have TWO subvolumes by
> "default"?  the regular one (current directory, "."):
>=20
> mount -o subvol=3D. <btrfs_dev> /mnt
>=20
> would behave as it does now.  BUT... there would then be a special,
> permanent (like "." is right now) subvol, say "parent directory"
> (".."):
>=20
> mount -o subvol=3D.. <btrfs_dev> /mnt
>=20
> TWO dots would mount the parent of ".", where i could then swap out
> the real default (".").
>=20
> would that work?

We do provide a set-default ioctl that can be used to change the defaul=
t
for the next mount.   This is pretty close to what you want, let me
think about ways to make it easier to use.

-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

  reply	other threads:[~2010-07-02  1:30 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
2010-06-30 14:26     ` C Anthony Risinger
2010-07-02  1:30       ` Chris Mason [this message]
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=20100702013054.GC15319@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).