Way to quickly "revert back" to a snapshot?

Way to quickly "revert back" to a snapshot?

[John Dong]

Suppose I want to do test something insane (like a massive OS update) to 
my system, and create a snapshot before doing so. Afterwards, if I 
decide my system is hosed and I'd like to revert back to the snapshot 
and forget any of this actually happened, what's the quickest way of 
doing it. It seems like by btrfs's design there should be a way to just 
"set the head" of the filesystem back to the snapshot, like git-reset, 
right?


John

Re: Way to quickly "revert back" to a snapshot?

[Chris Mason]

On Sat, Oct 17, 2009 at 01:20:28PM -0400, John Dong wrote:
> Suppose I want to do test something insane (like a massive OS
> update) to my system, and create a snapshot before doing so.
> Afterwards, if I decide my system is hosed and I'd like to revert
> back to the snapshot and forget any of this actually happened,
> what's the quickest way of doing it. It seems like by btrfs's design
> there should be a way to just "set the head" of the filesystem back
> to the snapshot, like git-reset, right?

This is near the top of the list of features I want to add for 2.6.33.
Basically all we need is a way to swap the default subvolume (which is
just a directory entry) pointer with another subvolume.

We also want a way to find an snapshot all the subvolumes and snapshots
underneath a given root.  That way the user won't have to do it
manually (snapshotting isn't recursive by default).

If anyone is interested in a coding project, both are fairly easy, just
let me know.

-chris

Re: Way to quickly "revert back" to a snapshot?

[TARUISI Hiroaki]

I'm trying to make this snapshots/subvolumes listing feature,
I wonder how the interface should be.

I tried to make this feature using ioctl interface, but I don't
know how to notify all subvolume informations because number
of subvolumes are not known before search.
(It may work, that we call number-notify ioctl before subvol-
 listing ioctl itself, or we call subvol-listing ioctl repeatedly
 to last subvolume. But both seem to be not good to me.)

Is there any other idea?

Chris Mason wrote:
> On Sat, Oct 17, 2009 at 01:20:28PM -0400, John Dong wrote:
>> Suppose I want to do test something insane (like a massive OS
>> update) to my system, and create a snapshot before doing so.
>> Afterwards, if I decide my system is hosed and I'd like to revert
>> back to the snapshot and forget any of this actually happened,
>> what's the quickest way of doing it. It seems like by btrfs's design
>> there should be a way to just "set the head" of the filesystem back
>> to the snapshot, like git-reset, right?
> 
> This is near the top of the list of features I want to add for 2.6.33.
> Basically all we need is a way to swap the default subvolume (which is
> just a directory entry) pointer with another subvolume.
> 
> We also want a way to find an snapshot all the subvolumes and snapshots
> underneath a given root.  That way the user won't have to do it
> manually (snapshotting isn't recursive by default).
> 
> If anyone is interested in a coding project, both are fairly easy, just
> let me know.
> 
> -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


-- 
taruisi

Re: Way to quickly "revert back" to a snapshot?

[Chris Mason]

On Fri, Oct 30, 2009 at 03:52:16PM +0900, TARUISI Hiroaki wrote:
> I'm trying to make this snapshots/subvolumes listing feature,
> I wonder how the interface should be.
> 
> I tried to make this feature using ioctl interface, but I don't
> know how to notify all subvolume informations because number
> of subvolumes are not known before search.
> (It may work, that we call number-notify ioctl before subvol-
>  listing ioctl itself, or we call subvol-listing ioctl repeatedly
>  to last subvolume. But both seem to be not good to me.)
> 
> Is there any other idea?

Thank you for working on this feature.

We find the subvolumes and snapshots by using the forward references in
the tree of tree roots, and the offset field of the key is set to the
root objectid of the subvolume/snapshot we have a reference on (see
root-tree.c:btrfs_add_root_ref())

So, my plan was to have a 'starting objectid' field in the struct we pass
from userland in the ioctl.   The ioctl would find the first reference
that is greater than the starting objectid.  rootid 0 is never used, so
passing zero is fine for the first call.

The ioctl would be called over and over again until it finds zero
subvols/snapshots.  I'd pass a buffer from userland so that it can
return a large list.

I think the ioctl should return the path name to the
subvolume/snapshot, which the kernel will have to find by walking the
directory back references up to the top level directory of the snapshot.
It will also need to return the root objectid so the application can
pass that into the next ioctl call.

Does this make sense?

-chris

Re: Way to quickly "revert back" to a snapshot?

[TARUISI Hiroaki]

Hi, Chris.

Thank you for your mail. It made big sense for me.
I'll try more, especially about search resuming for nested tree.

Chris Mason wrote:
> On Fri, Oct 30, 2009 at 03:52:16PM +0900, TARUISI Hiroaki wrote:
>> I'm trying to make this snapshots/subvolumes listing feature,
>> I wonder how the interface should be.
>>
>> I tried to make this feature using ioctl interface, but I don't
>> know how to notify all subvolume informations because number
>> of subvolumes are not known before search.
>> (It may work, that we call number-notify ioctl before subvol-
>>  listing ioctl itself, or we call subvol-listing ioctl repeatedly
>>  to last subvolume. But both seem to be not good to me.)
>>
>> Is there any other idea?
> 
> Thank you for working on this feature.
> 
> We find the subvolumes and snapshots by using the forward references in
> the tree of tree roots, and the offset field of the key is set to the
> root objectid of the subvolume/snapshot we have a reference on (see
> root-tree.c:btrfs_add_root_ref())
> 
> So, my plan was to have a 'starting objectid' field in the struct we pass
> from userland in the ioctl.   The ioctl would find the first reference
> that is greater than the starting objectid.  rootid 0 is never used, so
> passing zero is fine for the first call.
> 
> The ioctl would be called over and over again until it finds zero
> subvols/snapshots.  I'd pass a buffer from userland so that it can
> return a large list.
> 
> I think the ioctl should return the path name to the
> subvolume/snapshot, which the kernel will have to find by walking the
> directory back references up to the top level directory of the snapshot.
> It will also need to return the root objectid so the application can
> pass that into the next ioctl call.
> 
> Does this make sense?
> 
> -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

-- 
taruisi

Re: Way to quickly "revert back" to a snapshot?

[David Nicol]

On Fri, Oct 30, 2009 at 12:52 AM, TARUISI Hiroaki
<taruishi.hiroak@jp.fujitsu.com> wrote:
> I'm trying to make this snapshots/subvolumes listing feature,
> I wonder how the interface should be.
>
> Is there any other idea?

It's layers above where you're working, but how about providing a
virtual directory off the mounting root, like the lost+found
directories in other FSes, that would appear to contain them?

Re: Way to quickly "revert back" to a snapshot?

[Andrey Kuzmin]

/mountroot/.{snapshots,subvolumes} seems logical, works fine with
usual command-line/programmatic interfaces.

Regards,
Andrey



On Thu, Nov 5, 2009 at 12:57 AM, David Nicol <davidnicol@gmail.com> wro=
te:
> On Fri, Oct 30, 2009 at 12:52 AM, TARUISI Hiroaki
> <taruishi.hiroak@jp.fujitsu.com> wrote:
>> I'm trying to make this snapshots/subvolumes listing feature,
>> I wonder how the interface should be.
>>
>> Is there any other idea?
>
> It's layers above where you're working, but how about providing a
> virtual directory off the mounting root, like the lost+found
> directories in other FSes, that would appear to contain them?
> --
> 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 =A0http://vger.kernel.org/majordomo-info.html
>
--
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

Re: Way to quickly "revert back" to a snapshot?

[TARUISI Hiroaki]

Thank you for your ideas.

It will be nice we can get snapshot/subvolume information with
usual file/directory interface as you suggested, or like sysfs.

But, now I'm writing using ioctl interface, which may be good
enough for now.


Andrey Kuzmin wrote:
> /mountroot/.{snapshots,subvolumes} seems logical, works fine with
> usual command-line/programmatic interfaces.
> 
> Regards,
> Andrey
> 
> 
> 
> On Thu, Nov 5, 2009 at 12:57 AM, David Nicol <davidnicol@gmail.com> wrote:
>> On Fri, Oct 30, 2009 at 12:52 AM, TARUISI Hiroaki
>> <taruishi.hiroak@jp.fujitsu.com> wrote:
>>> I'm trying to make this snapshots/subvolumes listing feature,
>>> I wonder how the interface should be.
>>>
>>> Is there any other idea?
>> It's layers above where you're working, but how about providing a
>> virtual directory off the mounting root, like the lost+found
>> directories in other FSes, that would appear to contain them?
>> --
>> 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
>>
> --
> 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


-- 
taruisi