sub del: directory not empty, even though it is

sub del: directory not empty, even though it is

[Shaun Reich]

attempting to restructure my fs snapshots the proper way, previous way
was like this:

(subvol=0)
boot
etc
var
...
SNAPSHOTS/01-16-14/{boot,etc,dev, proc..}
SNAPSHOTS/03-22-14... etc

i removed all but the 01-16-14 via sub del. i then thought 'i don't
want the data at top-level anyways as its a botched upgrade, so i'll
just revert to the last snapshot via a mv.

so i rm'd everything at top level except snapshots, cd
snapshots/01-16-14;mv * ../..

now an ls -a at the dated dir shows empty, my files are where they
should be so i really just want this to be gone. and a sub list on the
top-level mount path lists:

# btrfs sub list -ta /mnt/1
ID      gen     top level       path
--      ---     ---------       ----
291     199502  5               SNAPSHOTS/01-16-14

yet, oddly enough btrfs sub del really doesn't want to delete it, even
though it's entirely empty and not in use either.

# btrfs sub del /mnt/1/SNAPSHOTS/01-16-14
Transaction commit: none (default)
Delete subvolume '/mnt/1/SNAPSHOTS/01-16-14'
ERROR: cannot delete '/mnt/1/SNAPSHOTS/01-16-14' - Directory not empty


-- 
Shaun Reich,
KDE Software Developer (kde.org)

Re: sub del: directory not empty, even though it is

[Chris Mason]

On 04/14/2014 12:50 PM, Shaun Reich wrote:
> attempting to restructure my fs snapshots the proper way, previous way
> was like this:
>
> (subvol=0)
> boot
> etc
> var
> ...
> SNAPSHOTS/01-16-14/{boot,etc,dev, proc..}
> SNAPSHOTS/03-22-14... etc
>
> i removed all but the 01-16-14 via sub del. i then thought 'i don't
> want the data at top-level anyways as its a botched upgrade, so i'll
> just revert to the last snapshot via a mv.
>
> so i rm'd everything at top level except snapshots, cd
> snapshots/01-16-14;mv * ../..
>
> now an ls -a at the dated dir shows empty, my files are where they
> should be so i really just want this to be gone. and a sub list on the
> top-level mount path lists:
>
> # btrfs sub list -ta /mnt/1
> ID      gen     top level       path
> --      ---     ---------       ----
> 291     199502  5               SNAPSHOTS/01-16-14
>
> yet, oddly enough btrfs sub del really doesn't want to delete it, even
> though it's entirely empty and not in use either.
>
> # btrfs sub del /mnt/1/SNAPSHOTS/01-16-14
> Transaction commit: none (default)
> Delete subvolume '/mnt/1/SNAPSHOTS/01-16-14'
> ERROR: cannot delete '/mnt/1/SNAPSHOTS/01-16-14' - Directory not empty

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.

The easiest way to clear it up is with btrfs-debug-tree.

If you're on a recent btrfs-progs:

btrfs-debug-tree -d /dev/xxxx > output.txt

gzip and send to me (privately).  It wont' contain any if your personal 
data, just the subvolume layout.

-chris

Re: sub del: directory not empty, even though it is

[Chris Mason]

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@oracle.com>
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@oracle.com>
    Signed-off-by: Guangyu Sun <guangyu.sun@oracle.com>
    Reviewed-by: David Sterba <dsterba@suse.cz>
    Signed-off-by: Chris Mason <clm@fb.com>

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

Re: sub del: directory not empty, even though it is

[Shaun Reich]

> Ok, latest kernels include this commit:
>
> commit 72de6b5393c15c5228074008bbdc47e92bf6d4f7
> Author: Guangyu Sun <guangyu.sun@oracle.com>
> 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@oracle.com>
>     Signed-off-by: Guangyu Sun <guangyu.sun@oracle.com>
>     Reviewed-by: David Sterba <dsterba@suse.cz>
>     Signed-off-by: Chris Mason <clm@fb.com>
>
> And your btrfs-debug-tree output confirms you're trying to delete the
> default subvolume.
>
> Pick a new default and it will all work ;)

yep, and that was (embarrassingly) it. set the default to 5, so i can
remove my use of subvolumes altogether and redo them properly. and the
delete of course succeeds now.

thanks

-- 
Shaun Reich,
KDE Software Developer (kde.org)