On 04/14/2014 02:48 PM, Chris Mason wrote:
> We have a pretty long list of reasons why the delete will fail, but the
> not empty one should only pop up if we think this snapshot has a
> reference on something else. I wonder if the mv didn't drop the refs.
>
Ok, latest kernels include this commit:
commit 72de6b5393c15c5228074008bbdc47e92bf6d4f7
Author: Guangyu Sun <guangyu.sun@xxxxxxxxxx>
Date: Tue Mar 11 11:24:18 2014 -0700
Btrfs: return EPERM when deleting a default subvolume
The error message is confusing:
# btrfs sub delete /mnt/mysub/
Delete subvolume '/mnt/mysub'
ERROR: cannot delete '/mnt/mysub' - Directory not empty
The error message does not make sense to me: It's not about deleting a
directory but it's a subvolume, and it doesn't matter if the subvolume is
empty or not.
Maybe EPERM or is more appropriate in this case, combined with an explanatory
kernel log message. (e.g. "subvolume with ID 123 cannot be deleted because
it is configured as default subvolume.")
Reported-by: Koen De Wit <koen.de.wit@xxxxxxxxxx>
Signed-off-by: Guangyu Sun <guangyu.sun@xxxxxxxxxx>
Reviewed-by: David Sterba <dsterba@xxxxxxx>
Signed-off-by: Chris Mason <clm@xxxxxx>
And your btrfs-debug-tree output confirms you're trying to delete the
default subvolume.
Pick a new default and it will all work ;)
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
