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 -- 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
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
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 -- 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
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
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 -- 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
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
/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
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 -- 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