Unexpected deletion behaviour between subvolume and normal directory

Unexpected deletion behaviour between subvolume and normal directory

[Robbie Smith]

I wanted to try to convert my music library from a directory into a
subvolume so I could use btrfs send/receive to transfer (changed)
files between it and a USB backup. A bit of Googling suggested that
the approach would be:

> btrfs subvolume create /library/newmusic
> cp -ar --reflink=auto /library/music/* /library/newmusic/.
> rm -r /library/music

After about 30 seconds I realised that it was deleting files from both
/library/music and /library/newmusic. It appears I've only lost
everything starting with A, B or C, so I unmounted the device, and am
currently trying to use `btrfs restore` to get the files back and it
doesn't seem to be finding them.

I'm pretty sure deleting files from directory A isn't supposed to also
delete them from directory B, but that's what it did. Is this a bug?

Robbie

Re: Unexpected deletion behaviour between subvolume and normal directory

[Holger Hoffstätte]

On 1/28/20 11:25 AM, Robbie Smith wrote:
> I wanted to try to convert my music library from a directory into a
> subvolume so I could use btrfs send/receive to transfer (changed)
> files between it and a USB backup. A bit of Googling suggested that
> the approach would be:
> 
>> btrfs subvolume create /library/newmusic
>> cp -ar --reflink=auto /library/music/* /library/newmusic/.
>> rm -r /library/music
> 
> After about 30 seconds I realised that it was deleting files from both
> /library/music and /library/newmusic. It appears I've only lost
> everything starting with A, B or C, so I unmounted the device, and am
> currently trying to use `btrfs restore` to get the files back and it
> doesn't seem to be finding them.
> 
> I'm pretty sure deleting files from directory A isn't supposed to also
> delete them from directory B, but that's what it did. Is this a bug?

Whatever happened - this is not it. I do this all the time without
problems. Also note that you can use mv directly, since it will
use reflink when possible:

$mkdir data
$echo "foo" > data/data
$btrfs subvolume create newdata
Create subvolume './newdata'
$mv data/* newdata
$ll data
total 0
$rm -rf data
$ll newdata
total 4.0K
-rw-r--r-- 1 root root 4 Jan 28 12:16 data
$cat newdata/data
foo

All as expected.

-h

Re: Unexpected deletion behaviour between subvolume and normal directory

[Nikolay Borisov]

On 28.01.20 г. 12:25 ч., Robbie Smith wrote:
> I wanted to try to convert my music library from a directory into a
> subvolume so I could use btrfs send/receive to transfer (changed)
> files between it and a USB backup. A bit of Googling suggested that
> the approach would be:
> 
>> btrfs subvolume create /library/newmusic
>> cp -ar --reflink=auto /library/music/* /library/newmusic/.
>> rm -r /library/music
> 
> After about 30 seconds I realised that it was deleting files from both
> /library/music and /library/newmusic. It appears I've only lost
> everything starting with A, B or C, so I unmounted the device, and am
> currently trying to use `btrfs restore` to get the files back and it
> doesn't seem to be finding them.
> 
> I'm pretty sure deleting files from directory A isn't supposed to also
> delete them from directory B, but that's what it did. Is this a bug?
> 

Can you reproduce the same thing with a simple test directory? I was not
able to reproduce it here?

> Robbie
> 

Re: Unexpected deletion behaviour between subvolume and normal directory

[Robbie Smith]

It turns out that I made a mistake when deleting the files: I typed
`rm -r /library/Music/*` instead of `rm -r /library/music/*` like I
intended. Substitute "Music" for "newmusic" in the examples above. So
I deleted files from the subvolume by mistake.

Now onto my next problem: `btrfs restore` is only able to recover
files that weren't yet deleted by my monumental stuff-up. It appears
`rm` went in alphabetical order, so I've lost only those artists that
started with A. B, or (some) C. However, systemd in its infinite
wisdom decided to automount my library drive while the restore was in
progress, and I suspect the space_cache mount option kicked in and
wiped the files forever. `btrfs-find-root` wasn't having much success,
but the undelete script here[1] is finding the files I wanted, so now
I'm just gradually working through everything.

I think I'll be able to recover most things.

[1]https://raw.githubusercontent.com/danthem/undelete-btrfs/master/undelete.sh

On Tue, 28 Jan 2020 at 22:38, Nikolay Borisov <nborisov@suse.com> wrote:
>
>
>
> On 28.01.20 г. 12:25 ч., Robbie Smith wrote:
> > I wanted to try to convert my music library from a directory into a
> > subvolume so I could use btrfs send/receive to transfer (changed)
> > files between it and a USB backup. A bit of Googling suggested that
> > the approach would be:
> >
> >> btrfs subvolume create /library/newmusic
> >> cp -ar --reflink=auto /library/music/* /library/newmusic/.
> >> rm -r /library/music
> >
> > After about 30 seconds I realised that it was deleting files from both
> > /library/music and /library/newmusic. It appears I've only lost
> > everything starting with A, B or C, so I unmounted the device, and am
> > currently trying to use `btrfs restore` to get the files back and it
> > doesn't seem to be finding them.
> >
> > I'm pretty sure deleting files from directory A isn't supposed to also
> > delete them from directory B, but that's what it did. Is this a bug?
> >
>
> Can you reproduce the same thing with a simple test directory? I was not
> able to reproduce it here?
>
> > Robbie
> >

Re: Unexpected deletion behaviour between subvolume and normal directory

[Robbie Smith]

On Wed, 29 Jan 2020 at 06:11, Chris Murphy <lists@colorremedies.com> wrote:
>
> On Tue, Jan 28, 2020 at 5:44 AM Robbie Smith <zoqaeski@gmail.com> wrote:
> >
> > It turns out that I made a mistake when deleting the files: I typed
> > `rm -r /library/Music/*` instead of `rm -r /library/music/*` like I
> > intended. Substitute "Music" for "newmusic" in the examples above. So
> > I deleted files from the subvolume by mistake.
> >
> > Now onto my next problem: `btrfs restore` is only able to recover
> > files that weren't yet deleted by my monumental stuff-up. It appears
> > `rm` went in alphabetical order, so I've lost only those artists that
> > started with A. B, or (some) C. However, systemd in its infinite
> > wisdom decided to automount my library drive while the restore was in
> > progress, and I suspect the space_cache mount option kicked in and
> > wiped the files forever. `btrfs-find-root` wasn't having much success,
> > but the undelete script here[1] is finding the files I wanted, so now
> > I'm just gradually working through everything.
> >
> > I think I'll be able to recover most things.
> >
> > [1]https://raw.githubusercontent.com/danthem/undelete-btrfs/master/undelete.sh
>
> If you avoid writes, there's a really good chance of a complete
> recovery. Even the metadata writes showing deletes tend to not be
> overwritten for a while, at least so long as neither the ssd mount
> option, nor discard mount option, are used.
>
> Space cache being updated could plausibly overwrite portions of data
> block groups; whereas space_cache=v2 is stored in metadata block
> groups.
>

It's a HDD so there's no SSD-specific mount options used. This drive
is (generally) only written to when I add new music or videos to my
multimedia library, and most of the files had existed on the drive for
months, if not years. As soon as I discovered my mistake, I made sure
there were no further writes to the drive.

It appears that the undelete script was able to find everything,
judging from the file names—btrfs restore wouldn't return a partial
file, would it? What exactly are its checks and balances to ensure
data integrity. if any? The undelete script didn't restore the
metadata (owner, perms, times) so I'm hoping rsync won't clobber
everything when I copy the files back. I don't have any means of
ensuring all the files are OK short of listening to the entire
collection for the nine weeks or so it would play, which is
unfeasible. I have tried just playing a dozen or so tracks picked at
random, and they played without errors. I do have an offsite backup,
but it can't be accessed remotely and it hasn't been updated for a
while.