On Wed, Jun 30, 2010 at 8:31 AM, Chris Mason <chris.ma...@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 <dan...@debian.org> wrote:
>> > Hi,
>> >
>> > this is basically a forward from
>> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587253
>> >
>> > "rename(2) allows for the atomic replacement of files. Being able to
>> > atomically replace subvolume snapshots would be equally invaluable,
>> > since it would permit lock-free replacement of subvolumes.
>> >
>> > % btrfs subvolume snapshot <src> <dest>
>> >
>> > creates dest as a snapshot of src. However, if I want to do the
>> > converse,
>> >
>> > % 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:
>> > I have a subvolume of data under active use, which I want to
>> > periodically update. I'd like to do this by atomically
>> > replacing its contents. I can replace the content right now
>> > by deleting the old subvolume and then snapshotting the new
>> > on in its place, but it's racy. It really needs to be
>> > replaced in a single operation, or else there's a small window
>> > where there is no data, and I'd need to resort to some external
>> > locking 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 to
> do?
>
>> >
>> > Use case 2:
>> > In schroot, we create btrfs subvolume snapshots to get copy-on-
>> > write chroots. This works just fine. We also provide direct
>> > access to the "source" subvolume, but since it could be
>> > snapshotted in an inconsistent state while being updated, we
>> > want to do the following:
>> >
>> > · snapshot source subvolume
>> > · update snapshot
>> > · 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 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 thread
>> it's in:
>>
>> http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg05278.html
>>
>> is there any feedback on these actions? no one seems to even respond :-(
>>
>> 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.
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?
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.
what about this: would it be possible to have TWO subvolumes by
"default"? the regular one (current directory, "."):
mount -o subvol=. <btrfs_dev> /mnt
would behave as it does now. BUT... there would then be a special,
permanent (like "." is right now) subvol, say "parent directory"
(".."):
mount -o subvol=.. <btrfs_dev> /mnt
TWO dots would mount the parent of ".", where i could then swap out
the real default (".").
would that work?
C Anthony
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
