All of lore.kernel.org
 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 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.