snapshot/subvolume removal

snapshot/subvolume removal

[Piavlo]

 Hi,

Does btrfs support snapshot or/and subvolume removal ?
If yes how, since I could not find the commands to do that?
If not is there any estimation when this feature will be available?

Is there a tool to list the existing subvolumes/snapshots?

It looks like the snapshots can overridden by subvolumes, see below:

shell>  btrfsctl  -s rsync-snap rsync
operation complete
Btrfs v0.19-4-gab8fb4c-dirty
shell>  btrfsctl  -S rsync-snap rsync
operation complete
Btrfs v0.19-4-gab8fb4c-dirty
shell> btrfsctl  -s rsync-snap rsync
ioctl:: File exists
shell>

Is that expected?
What happens to the snapshot  then it is overridden by subvolume?
It does not seem reasonable that snapshot can be converted into 
subvolume, since newly created subvolume
holds no data ,while the snapshot is a snapshot of other previously
existing subvolume and holds data.
So is snapshots simply destroyed prior to subvolume creation, in the
above scenario?

 Thanks
 Alex

Re: snapshot/subvolume removal

[TARUISI Hiroaki]

Hi,

We can delete snapshot with btrfsctl -D . It's available for
your btrfs-progs version.

And parameters of btrfsctl -s/S are not coherent at the last
argument.
In creating snapshots, the last argument implies the directory
where subvolume is to be created, but in taking snapshots,
the last argument implies subvolume we take snapshot of, and
snapshots are created under current directory.

So,
> shell>  btrfsctl  -s rsync-snap rsync
> operation complete

snapshot rsync-snap is created under current directory, and,

> Btrfs v0.19-4-gab8fb4c-dirty
> shell>  btrfsctl  -S rsync-snap rsync
> operation complete

subvolume rsync-snap is created under rsync directory in current
directory. They are created under different directories.

Regards,
taruisi

(2010/01/06 6:18), Piavlo wrote:
>  Hi,
> 
> Does btrfs support snapshot or/and subvolume removal ?
> If yes how, since I could not find the commands to do that?
> If not is there any estimation when this feature will be available?
> 
> Is there a tool to list the existing subvolumes/snapshots?
> 
> It looks like the snapshots can overridden by subvolumes, see below:
> 
> shell>  btrfsctl  -s rsync-snap rsync
> operation complete
> Btrfs v0.19-4-gab8fb4c-dirty
> shell>  btrfsctl  -S rsync-snap rsync
> operation complete
> Btrfs v0.19-4-gab8fb4c-dirty
> shell> btrfsctl  -s rsync-snap rsync
> ioctl:: File exists
> shell>
> 
> Is that expected?
> What happens to the snapshot  then it is overridden by subvolume?
> It does not seem reasonable that snapshot can be converted into 
> subvolume, since newly created subvolume
> holds no data ,while the snapshot is a snapshot of other previously
> existing subvolume and holds data.
> So is snapshots simply destroyed prior to subvolume creation, in the
> above scenario?
> 
>  Thanks
>  Alex
> 
> --
> 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: snapshot/subvolume removal

[Adrian von Bidder]

[-- Attachment #1: Type: Text/Plain, Size: 941 bytes --]

On Wednesday 06 January 2010 01.30:35 TARUISI Hiroaki wrote:
> In creating snapshots, the last argument implies the directory
> where subvolume is to be created, but in taking snapshots,
> the last argument implies subvolume we take snapshot of, and
> snapshots are created under current directory.
> 

This was a bit confusing to me at first, too.  (But obviously '-s' needs the 
input which volume to take the snapshot from.)

Would it be a good idea to make btrfsctl -s fail if the last argument is not 
the root of a subvolume?  That way, the directory given to "btrfsctl -s" 
would always match what ends up in a snapshot.  (It is a bit strange for 
people who are not familiar with btrfs to do "btrfsctl -s snap 
some/directory/somewhere" and then realize that the snapshot is created from 
"some" and not from "somewhere" because "some" is the subvolume root.)

cheers
-- vbi

-- 
Pushing 40 is exercise enough.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 389 bytes --]

Re: snapshot/subvolume removal

[Piavlo]

TARUISI Hiroaki wrote:
> Hi,
>
> We can delete snapshot with btrfsctl -D . It's available for
> your btrfs-progs version.
-D works great

Also how can I know if some directory is subvolume or snapshot or just a
normal directory?
Is there a way to list all the existing snapshots & subvolumes under btrfs?

Thanks
Alex

Re: snapshot/subvolume removal

[TARUISI Hiroaki]

For now, subvolumes and snapshots look like just directories.
If you want to distinguish them, there's only an unusual way,
that is, analyzing with btrfs-debug-tree.

I posted patches for listing snapshots/subvolumes two months ago,
and Josef Bacik posted its bugfix patch. This feature may be
delivered in sooner or later.
If you want to try it now, check these URLs.
  http://patchwork.kernel.org/patch/60923/raw/
  http://patchwork.kernel.org/patch/60920/raw/
  http://patchwork.kernel.org/patch/67332/raw/
Patches and requests are welcome.

Regards,
taruisi

(2010/01/06 17:33), Piavlo wrote:
> TARUISI Hiroaki wrote:
>> Hi,
>>
>> We can delete snapshot with btrfsctl -D . It's available for
>> your btrfs-progs version.
> -D works great
> 
> Also how can I know if some directory is subvolume or snapshot or just a
> normal directory?
> Is there a way to list all the existing snapshots & subvolumes under btrfs?
> 
> Thanks
> Alex
> 
> --
> 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: snapshot/subvolume removal

[Piavlo]

TARUISI Hiroaki wrote:
> For now, subvolumes and snapshots look like just directories.
> If you want to distinguish them, there's only an unusual way,
> that is, analyzing with btrfs-debug-tree.
>
> I posted patches for listing snapshots/subvolumes two months ago,
> and Josef Bacik posted its bugfix patch. This feature may be
> delivered in sooner or later.
> If you want to try it now, check these URLs.
>   http://patchwork.kernel.org/patch/60923/raw/
>   http://patchwork.kernel.org/patch/60920/raw/
>   http://patchwork.kernel.org/patch/67332/raw/
>   
Thanks for pointing me all the needed patched, the btrfsctl -l is
working for me fine.
> Patches and requests are welcome.
>   
Currently btrfsctl -l show only which directories are
snapshots/subvolumes, it would be nice if it would also show
a hierarchy of snapshots i.e. from which subvolume/snapshot a specific
snapshot was taken from.

For example:

/ # cd /.btrfs
/.btrfs #  btrfsctl -l /.btrfs
   Base path = /.btrfs/
   No.     Tree ID      Subvolume Relative Path
    1          275      rootfs-old/
    2          277      rootfs/
operation complete
Btrfs v0.19-4-gab8fb4c-dirty
/.btrfs # btrfsctl -S subvol0 .
operation complete
Btrfs v0.19-4-gab8fb4c-dirty
/.btrfs #  btrfsctl -l /.btrfs/
   Base path = /.btrfs/
   No.     Tree ID      Subvolume Relative Path
    1          275      rootfs-old/
    2          277      rootfs/
    3          279      subvol0/
operation complete
Btrfs v0.19-4-gab8fb4c-dirty
/.btrfs # btrfsctl -s subvol0-snap subvol0
operation complete
Btrfs v0.19-4-gab8fb4c-dirty
/.btrfs # btrfsctl -s subvol0/subvol1-snap subvol0
operation complete
Btrfs v0.19-4-gab8fb4c-dirty
/.btrfs # btrfsctl -s subvol1-snap-snap subvol0/subvol1-snap
operation complete
Btrfs v0.19-4-gab8fb4c-dirty
/.btrfs #  btrfsctl -l /.btrfs/
   Base path = /.btrfs/
   No.     Tree ID      Subvolume Relative Path
    1          275      rootfs-old/
    2          277      rootfs/
    3          279      subvol0/
    4          281      subvol0/subvol1-snap/
    5          280      subvol0-snap/
    6          282      subvol1-snap-snap/
operation complete
Btrfs v0.19-4-gab8fb4c-dirty
/ .btrfs #                   

It would be nice if it would possible to show the youngest snapshot
ancestor  - something like this:

 /.btrfs #  btrfsctl -l /.btrfs/
   Base path = /.btrfs/
   No.     Tree ID      Subvolume Relative Path       Snapshot Ancestor
    1          275      rootfs-old/                                  none
    2          277      rootfs/                                        
rootfs-old/
    3          279      subvol0/                                      none
    4          281      subvol0/subvol1-snap/                subvol0/
    5          280      subvol0-snap/                              subvol0/
    6          282      subvol1-snap-snap/                    
subvol0/subvol1-snap/
operation complete
Btrfs v0.19-4-gab8fb4c-dirty
/.btrfs #  btrfsctl -D subvol1-snap subvol0
operation complete
Btrfs v0.19-4-gab8fb4c-dirty
/.btrfs #  btrfsctl -l .
   Base path = /.btrfs/
   No.     Tree ID      Subvolume Relative Path    Snapshot Ancestor
    1          275      rootfs-old/                                none
    2          277      rootfs/                                      
rootfs-old/
    3          279      subvol0/                                    none
    4          280      subvol0-snap/                           subvol0/
    5          282      subvol1-snap-snap/                   subvol0/
operation complete
Btrfs v0.19-4-gab8fb4c-dirty
/.btrfs #  btrfsctl -D subvol0 .
operation complete
Btrfs v0.19-4-gab8fb4c-dirty
/.btrfs #  btrfsctl -l .
   Base path = /.btrfs/
   No.     Tree ID      Subvolume Relative Path     Snapshot Origin
    1          275      rootfs-old/                                  none
    2          277      rootfs/                                       
rootfs-old/
    3          280      subvol0-snap/                            none
    4          282      subvol1-snap-snap/                    none
operation complete
Btrfs v0.19-4-gab8fb4c-dirty
/.btrfs #          

Thanks
Alex

Re: snapshot/subvolume removal

[TARUISI Hiroaki]

Thanks for your comment.

I think your request is reasonable but because there's
no information about a hierachy of snapshots in filesystem,
we cannot know it for now.

In future, these information may be supplied by application
programs which manage all snapshots or backups.

Regards,
taruisi

(2010/01/10 07:01), Piavlo wrote:
> TARUISI Hiroaki wrote:
>> For now, subvolumes and snapshots look like just directories.
>> If you want to distinguish them, there's only an unusual way,
>> that is, analyzing with btrfs-debug-tree.
>>
>> I posted patches for listing snapshots/subvolumes two months ago,
>> and Josef Bacik posted its bugfix patch. This feature may be
>> delivered in sooner or later.
>> If you want to try it now, check these URLs.
>>    http://patchwork.kernel.org/patch/60923/raw/
>>    http://patchwork.kernel.org/patch/60920/raw/
>>    http://patchwork.kernel.org/patch/67332/raw/
>>
> Thanks for pointing me all the needed patched, the btrfsctl -l is
> working for me fine.
>> Patches and requests are welcome.
>>
> Currently btrfsctl -l show only which directories are
> snapshots/subvolumes, it would be nice if it would also show
> a hierarchy of snapshots i.e. from which subvolume/snapshot a specific
> snapshot was taken from.
>
> For example:
>
> / # cd /.btrfs
> /.btrfs #  btrfsctl -l /.btrfs
>     Base path = /.btrfs/
>     No.     Tree ID      Subvolume Relative Path
>      1          275      rootfs-old/
>      2          277      rootfs/
> operation complete
> Btrfs v0.19-4-gab8fb4c-dirty
> /.btrfs # btrfsctl -S subvol0 .
> operation complete
> Btrfs v0.19-4-gab8fb4c-dirty
> /.btrfs #  btrfsctl -l /.btrfs/
>     Base path = /.btrfs/
>     No.     Tree ID      Subvolume Relative Path
>      1          275      rootfs-old/
>      2          277      rootfs/
>      3          279      subvol0/
> operation complete
> Btrfs v0.19-4-gab8fb4c-dirty
> /.btrfs # btrfsctl -s subvol0-snap subvol0
> operation complete
> Btrfs v0.19-4-gab8fb4c-dirty
> /.btrfs # btrfsctl -s subvol0/subvol1-snap subvol0
> operation complete
> Btrfs v0.19-4-gab8fb4c-dirty
> /.btrfs # btrfsctl -s subvol1-snap-snap subvol0/subvol1-snap
> operation complete
> Btrfs v0.19-4-gab8fb4c-dirty
> /.btrfs #  btrfsctl -l /.btrfs/
>     Base path = /.btrfs/
>     No.     Tree ID      Subvolume Relative Path
>      1          275      rootfs-old/
>      2          277      rootfs/
>      3          279      subvol0/
>      4          281      subvol0/subvol1-snap/
>      5          280      subvol0-snap/
>      6          282      subvol1-snap-snap/
> operation complete
> Btrfs v0.19-4-gab8fb4c-dirty
> / .btrfs #
>
> It would be nice if it would possible to show the youngest snapshot
> ancestor  - something like this:
>
>   /.btrfs #  btrfsctl -l /.btrfs/
>     Base path = /.btrfs/
>     No.     Tree ID      Subvolume Relative Path       Snapshot Ancestor
>      1          275      rootfs-old/                                  none
>      2          277      rootfs/
> rootfs-old/
>      3          279      subvol0/                                      none
>      4          281      subvol0/subvol1-snap/                subvol0/
>      5          280      subvol0-snap/                              subvol0/
>      6          282      subvol1-snap-snap/
> subvol0/subvol1-snap/
> operation complete
> Btrfs v0.19-4-gab8fb4c-dirty
> /.btrfs #  btrfsctl -D subvol1-snap subvol0
> operation complete
> Btrfs v0.19-4-gab8fb4c-dirty
> /.btrfs #  btrfsctl -l .
>     Base path = /.btrfs/
>     No.     Tree ID      Subvolume Relative Path    Snapshot Ancestor
>      1          275      rootfs-old/                                none
>      2          277      rootfs/
> rootfs-old/
>      3          279      subvol0/                                    none
>      4          280      subvol0-snap/                           subvol0/
>      5          282      subvol1-snap-snap/                   subvol0/
> operation complete
> Btrfs v0.19-4-gab8fb4c-dirty
> /.btrfs #  btrfsctl -D subvol0 .
> operation complete
> Btrfs v0.19-4-gab8fb4c-dirty
> /.btrfs #  btrfsctl -l .
>     Base path = /.btrfs/
>     No.     Tree ID      Subvolume Relative Path     Snapshot Origin
>      1          275      rootfs-old/                                  none
>      2          277      rootfs/
> rootfs-old/
>      3          280      subvol0-snap/                            none
>      4          282      subvol1-snap-snap/                    none
> operation complete
> Btrfs v0.19-4-gab8fb4c-dirty
> /.btrfs #
>
> Thanks
> Alex

Re: snapshot/subvolume removal

[Piavlo]

TARUISI Hiroaki wrote:
> Thanks for your comment.
>
> I think your request is reasonable but because there's
> no information about a hierachy of snapshots in filesystem,
> we cannot know it for now.
>
> In future, these information may be supplied by application
> programs which manage all snapshots or backups.
>   
Maintaining snapshot hierarchy by  external application is not reliable
and error prone
compared to maintaining it withing the btrfs itself,
probably by adding the parent treeid field for every  shapshot/subvolume.

Thanks
Alex

Re: snapshot/subvolume removal

[TARUISI Hiroaki]

Yes, it's not enough reliable for all users, and it may be
possible, but disk format may be the last point to change.

If we want to change it, we need to discuss its necessity
carefully and implement it [almost] without incompatibility.

Regards,
taruisi

(2010/01/12 16:08), Piavlo wrote:
> TARUISI Hiroaki wrote:
>> Thanks for your comment.
>>
>> I think your request is reasonable but because there's
>> no information about a hierachy of snapshots in filesystem,
>> we cannot know it for now.
>>
>> In future, these information may be supplied by application
>> programs which manage all snapshots or backups.
>>   
> Maintaining snapshot hierarchy by  external application is not reliable
> and error prone
> compared to maintaining it withing the btrfs itself,
> probably by adding the parent treeid field for every  shapshot/subvolume.
> 
> Thanks
> Alex
> 

Re: snapshot/subvolume removal

[Adrian von Bidder]

[-- Attachment #1: Type: Text/Plain, Size: 617 bytes --]

Hi,

On Tuesday 12 January 2010 08.08:26 Piavlo wrote:
> Maintaining snapshot hierarchy by  external application is not reliable
> and error prone
> compared to maintaining it withing the btrfs itself,
> probably by adding the parent treeid field for every  shapshot/subvolume.

What should, in your opinion, happen if the parent snapshot is deleted?  
Orphan? Re-parent to parent of parent?  I guess depending on application, 
there may be more than one "right" solution.

cheers
-- vbi

-- 
When Al sends me patches, I apply them.
I worry what would happen if I didn't.
        -- Linus Torvalds

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 389 bytes --]

Re: snapshot/subvolume removal

[Piavlo]

Adrian von Bidder wrote:
> Hi,
>
> On Tuesday 12 January 2010 08.08:26 Piavlo wrote:
>   
>> Maintaining snapshot hierarchy by  external application is not reliable
>> and error prone
>> compared to maintaining it withing the btrfs itself,
>> probably by adding the parent treeid field for every  shapshot/subvolume.
>>     
>
> What should, in your opinion, happen if the parent snapshot is deleted?  
> Orphan? Re-parent to parent of parent?
Re-parent to parent of parent.
And if there is no grandparent then  point to itself (like with root
directory).
This hierarchy should be tracked/modifed within same subvolume only - so
each subvolume has it's own snapshots hierarchy.
This would allow, for example, easy rollback of most recent subvolume
state to previous states (probably with btrfsctl)  without maintaining
snapshots hierarchy state in userspace applications.

 Thanks
  Alex
>   I guess depending on application, 
> there may be more than one "right" solution.
>
> cheers
> -- vbi
>
>   

Re: snapshot/subvolume removal

[Chris Mason]

On Fri, Jan 08, 2010 at 05:28:42PM +0900, TARUISI Hiroaki wrote:
> For now, subvolumes and snapshots look like just directories.
> If you want to distinguish them, there's only an unusual way,
> that is, analyzing with btrfs-debug-tree.
> 
> I posted patches for listing snapshots/subvolumes two months ago,
> and Josef Bacik posted its bugfix patch. This feature may be
> delivered in sooner or later.
> If you want to try it now, check these URLs.
>   http://patchwork.kernel.org/patch/60923/raw/
>   http://patchwork.kernel.org/patch/60920/raw/
>   http://patchwork.kernel.org/patch/67332/raw/
> Patches and requests are welcome.

Thanks again for the subvolume listing patch, it's going to be a great
feature.

I'm afraid I've had to make some small changes.  ioctls have
some very strict rules for the arguments, and pointers and list heads
should not be passed in ioctl structs.

We also need to change the patch to make the ioct args struct the same
size on both 32 bit and 64 bit machines, which usually just means
aligning and padding the fields as required.

I have started on this and hope to finish it on Tuesday.  But if you
have any additions to the patch please let me know.

-chris

Re: snapshot/subvolume removal

[TARUISI Hiroaki]

Thanks for reply and changing.

I planned one more patch to list up all subvolumes
under fs tree. This must be useful in case of
mounting with subvol parameter.

Regards,
taruisi

(2010/01/11 5:18), Chris Mason wrote:
> On Fri, Jan 08, 2010 at 05:28:42PM +0900, TARUISI Hiroaki wrote:
>> For now, subvolumes and snapshots look like just directories.
>> If you want to distinguish them, there's only an unusual way,
>> that is, analyzing with btrfs-debug-tree.
>>
>> I posted patches for listing snapshots/subvolumes two months ago,
>> and Josef Bacik posted its bugfix patch. This feature may be
>> delivered in sooner or later.
>> If you want to try it now, check these URLs.
>>   http://patchwork.kernel.org/patch/60923/raw/
>>   http://patchwork.kernel.org/patch/60920/raw/
>>   http://patchwork.kernel.org/patch/67332/raw/
>> Patches and requests are welcome.
> 
> Thanks again for the subvolume listing patch, it's going to be a great
> feature.
> 
> I'm afraid I've had to make some small changes.  ioctls have
> some very strict rules for the arguments, and pointers and list heads
> should not be passed in ioctl structs.
> 
> We also need to change the patch to make the ioct args struct the same
> size on both 32 bit and 64 bit machines, which usually just means
> aligning and padding the fields as required.
> 
> I have started on this and hope to finish it on Tuesday.  But if you
> have any additions to the patch please let me know.
> 
> -chris