Re: snapshot/subvolume removal
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 -- 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
Re: snapshot/subvolume removal
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 signature.asc Description: This is a digitally signed message part.
Re: snapshot/subvolume removal
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 -- 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
Re: snapshot/subvolume removal
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 PathSnapshot 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 -- 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
Re: snapshot/subvolume removal
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 -- 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
Re: snapshot/subvolume removal
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 -- 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
Re: snapshot/subvolume removal
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 -- 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
Re: snapshot/subvolume removal
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 majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: snapshot/subvolume removal
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: snapshot/subvolume removal
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 majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: snapshot/subvolume removal
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. signature.asc Description: This is a digitally signed message part.
