Warn to terminal that subvolume is default on deletion intent

Warn to terminal that subvolume is default on deletion intent

[Damian Stevenson]

# Error description
Trying to delete subvolume which is set as default, not allowed.
States reason to dmesg but not to terminal.

# Request:
Output to terminal as well, the reason why can't delete subvolume. In
example: because subvolume is set as default on deletion intent. As
user I didn't knew I had to follow dmesg, read it just out of luck.

# Environment
uname -a
Linux damian 5.4.0-33-generic #37-Ubuntu SMP Thu May 21 12:53:59 UTC
2020 x86_64 x86_64 x86_64 GNU/Linux

btrfs --version
btrfs-progs v5.4.1

sudo btrfs fi show
Label: none  uuid: c41a0bb3-2e82-314c-456a-cffda8400b36
Total devices 1 FS bytes used 11.95GiB
devid    1 size 180.00GiB used 16.07GiB path /dev/nbd3p1

btrfs fi df /drive/
Data, single: total=14.01GiB, used=11.23GiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, DUP: total=1.00GiB, used=89.67MiB
GlobalReserve, single: total=12.84MiB, used=0.00B

dmesg | grep BTRFS
[  221.769923] BTRFS: device fsid c41a0bb3-2e82-314c-456a-cffda8400b36
devid 1 transid 1039 /dev/nbd3p1
[  253.000241] BTRFS info (device nbd3p1): disk space caching is enabled
[  253.000244] BTRFS info (device nbd3p1): has skinny extents
[  253.093369] BTRFS info (device nbd3p1): enabling ssd optimizations
[ 1359.791080] BTRFS info (device nbd3p1): disk space caching is enabled
[ 1359.791081] BTRFS info (device nbd3p1): has skinny extents
[ 1359.870093] BTRFS info (device nbd3p1): enabling ssd optimizations

# Current behavior -> error replication:
sudo mount -t btrfs -o subvolid=5 /dev/nbd3p1 /drive/

sudo btrfs subvolume create /drive/newvol
Create subvolume '/drive/newvol'

sudo btrfs subvolume list /drive
ID 464 gen 1190 top level 5 path newvol

sudo btrfs subvolume set-default 464 /drive/

sudo btrfs subvolume get-default  /drive/
ID 464 gen 1190 top level 5 path newvol

# On deletion intent
sudo btrfs subvolume delete /drive/newvol/
Delete subvolume (no-commit): '/drive/newvol'
ERROR: Could not destroy subvolume/snapshot: Operation not permitted

dmesg | grep BTRFS
[ 5160.908633] BTRFS error (device nbd3p1): deleting default subvolume
464 is not allowed

# Effective deletion
sudo btrfs subvolume set-default 5 /drive/

sudo btrfs subvolume delete /drive/newvol/
Delete subvolume (no-commit): '/drive/newvol'

# Bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=207975

Re: Warn to terminal that subvolume is default on deletion intent

[David Sterba]

On Fri, May 29, 2020 at 05:14:20PM +0200, Damian Stevenson wrote:
> # Error description
> Trying to delete subvolume which is set as default, not allowed.
> States reason to dmesg but not to terminal.
> 
> # Request:
> Output to terminal as well, the reason why can't delete subvolume. In
> example: because subvolume is set as default on deletion intent. As
> user I didn't knew I had to follow dmesg, read it just out of luck.

Thanks for the detailed report. You're right, this should be printed as
an error message.

> # On deletion intent
> sudo btrfs subvolume delete /drive/newvol/
> Delete subvolume (no-commit): '/drive/newvol'
> ERROR: Could not destroy subvolume/snapshot: Operation not permitted

This is easy to fix, if anybody wants to take it, if the subvolume
deletion returns -1 and EPERM, then check if the subvolume is default
(btrfs_util_get_default_subvolume_fd) and then print the message.

Additionally, if there's EPERM and the subvolume is not default, it's
either race (the subvolume lost the default status meanwhie), or there's
send in progress. As this could be also confusing, fixing both would be
welcome.

> https://bugzilla.kernel.org/show_bug.cgi?id=207975

I've cross-referenced in github/btrfs-progs issue.