Skip to contentSkip to conversation

snapshot/subvolume removal

DISCUSSION Piavlo 4 participants 13 messages Jan 5, 2010 – Jan 12, 2010 Btrfs file system

lore
Share & tools
lore

Piavlo

author
#0 lore raw

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

#1 lore raw

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,

Quoted 2 lines

shell> btrfsctl -s rsync-snap rsync
operation complete

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

Quoted 3 lines

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

Quoted 36 lines · 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

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw
Quoted 5 lines · 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

Signature · 1 line
Pushing 40 is exercise enough.
author
#3 lore raw
In reply to TARUISI Hiroaki
Quoted 4 lines · TARUISI Hiroaki

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

#4 lore raw

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

Quoted 18 lines · Piavlo
Quoted 4 lines · TARUISI Hiroaki

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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#5 lore raw
Quoted 4 lines · 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.

Quoted 8 lines

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.

Quoted 2 lines

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

#6 lore raw

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

Quoted 112 lines · Piavlo
Quoted 4 lines · 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.

Quoted 8 lines

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.

Quoted 2 lines

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

author
#7 lore raw
Quoted 9 lines · 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.

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

#8 lore raw

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

Quoted 18 lines · Piavlo
Quoted 9 lines · 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.

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

#9 lore raw
In reply to Piavlo

Hi,

Quoted 4 lines · 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

Signature · 3 lines
When Al sends me patches, I apply them.
I worry what would happen if I didn't.
        -- Linus Torvalds
author
#10 lore raw
Quoted 4 lines · Adrian von Bidder

Hi,

On Tuesday 12 January 2010 08.08:26 Piavlo wrote:

Quoted 8 lines
Quoted 5 lines

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

Quoted 7 lines

I guess depending on application,
there may be more than one "right" solution.

cheers
-- vbi

#11 lore raw
In reply to TARUISI Hiroaki
Quoted 4 lines · 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.

Quoted 8 lines

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

#12 lore raw

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

Quoted 29 lines · Chris Mason
Quoted 4 lines · 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.

Quoted 8 lines

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