That's because the test shouldn't be in your root in the first place.
The common way of thinking now is to create a btrfs volume with a
structure for holding subvolumes inside of which your system root is a
member. You then mount the system root via -o subvol= and will only
see it and nothing else. If you want access to the control structure
you mount that without -o subvol. If you want to mount another
subvolume (even in place of your root) you mount that with -o subvol
to whereever you want.
Examples:
real btrfs root:
/root/default
/root/snap1
/root/snap2
/home/default
/home/snap1
The system root mounts /root/default on boot via -o
subvol=root/default as well as the /home/default subvolume for /home.
Then if you want to make a snapshot you mount btrfs to something like
/mnt/ctrl and do 'btrfs sub snap / /mnt/ctrl/root/snap3' and umount
/mnt/ctrl again.
Rolling back a snapshot is as easy as mounting /mnt/ctrl and doing 'mv
/mnt/ctrl/root/default /mnt/ctrl/root/default-old mv
/mnt/ctrl/root/snap3 /mnt/ctrl/root/default' followed by a reboot. No
changes are necessary to your boot system and on the next boot you are
rolled back and can delete the default-old subvol if you desire.
On Thu, Mar 14, 2013 at 5:24 AM, Queen Adam adam900...@gmail.com wrote:
Hi all,
When using btrfs sub create test commands to create a subvolume, it
will create test directory in the current directory.
But the subvol directory can only be delete by btrfs sub delete
command, which seems also delete all the data in the subvolume.
Any method about the 'umount'-like method to 'umount' the subvolume
and delete the subvolume directory without deleting all the data?
The method now seems less flexible (can mount -o subvol=test to other
path but the test/ can't be deleted)
Thanks.
--
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