Re: How to recover from failing btrfs send | btrfs receive?

[Marc MERLIN <marc@merlins.org>]

On Sun, Feb 16, 2014 at 03:38:18PM +0000, Filipe David Manana wrote:
> On Sun, Feb 16, 2014 at 2:23 PM, Marc MERLIN <marc@merlins.org> wrote:
> > Hi Fillipe, I see you have another fix for btrfs send (attached below),
> > as ell as your other patch on Jan 21st (neither are in my 3.12.7).
> 
> Hi Marc,
> Some replies below inlined.

The proper way to answer Email, thank you :)

> > From my error below,
> >> ERROR: rmdir o1845158-142-0 failed. No such file or directory
> > can you tell if I'm having a different problem than the two patches
> > you sent?
> 
> I think it's a different problem.
> The issues I have been fixing are about child directories with lower
> inode numbers then their parents and renaming/moving them.
 
Got it, thanks for letting me know.

> > More generally, could you hint how I can tell what this
> >  rmdir o1845158-142-0
> > refers to, considering that it looks like a made up filename by btrfs
> > send/receive?
> 
> Those ox-y-z names are for orphan inodes, and generated by btrfs send yes.

Good to know, thanks.

> Since you don't seem to know the sequence of steps (filesystem ops)
> that lead to that issue, perhaps you can run 'tree -a --inodes'

Nope, only had it once and it was on my home directory, which gets a lot of changes.
If I had a way to know which filename o1845158-142-0 refers to, it would help :)

Ahh, I see that I do, grepped for inode 1818495 in tree -adf --inodes | less

You don't want me to send the output, it's megabytes worth, but here's what changed:

Before:
/mnt/btrfs_pool1/home_ro.20140209_12:00:01/merlin:
├── [1845158]  ./gg-src/chromiumos/chroot/usr/share/zoneinfo/posix/America
│   ├── [1845159]  ./gg-src/chromiumos/chroot/usr/share/zoneinfo/posix/America/Argentina
│   ├── [1845172]  ./gg-src/chromiumos/chroot/usr/share/zoneinfo/posix/America/Indiana
│   ├── [1845181]  ./gg-src/chromiumos/chroot/usr/share/zoneinfo/posix/America/Kentucky
│   └── [1845184]  ./gg-src/chromiumos/chroot/usr/share/zoneinfo/posix/America/North_Dakota

In my new subvolume, I have this instead (directory is indeed gone, there are other 2 with the same name/hierachy, maybe even the same contents):

After:
/mnt/btrfs_pool1/home/merlin:
legolas:~/gg-src$  tree -adf --inodes | grep zoneinfo/posix/America
    │   ├── [4172524]  ./ProdNG/PNG_test/chroots/borg/usr/share/zoneinfo/posix/America
    │   │   ├── [4172733]  ./ProdNG/PNG_test/chroots/borg/usr/share/zoneinfo/posix/America/Argentina
    │   │   ├── [4172734]  ./ProdNG/PNG_test/chroots/borg/usr/share/zoneinfo/posix/America/Indiana
    │   │   ├── [4172735]  ./ProdNG/PNG_test/chroots/borg/usr/share/zoneinfo/posix/America/Kentucky
    │   │   └── [4172736]  ./ProdNG/PNG_test/chroots/borg/usr/share/zoneinfo/posix/America/North_Dakota
├── [4188826]  ./ProdNG/PNG_test/usr/share/zoneinfo/posix/America
│   ├── [4189034]  ./ProdNG/PNG_test/usr/share/zoneinfo/posix/America/Argentina
│   ├── [4189035]  ./ProdNG/PNG_test/usr/share/zoneinfo/posix/America/Indiana
│   ├── [4189036]  ./ProdNG/PNG_test/usr/share/zoneinfo/posix/America/Kentucky
│   └── [4189037]  ./ProdNG/PNG_test/usr/share/zoneinfo/posix/America/North_Dakota


> against the root of the subvolume and lets us know what the full
> output is. That might help in case it's one more case similar to those
> I have been fixing recently.

Does this help?

I still have the snapshot send/received failed at and the current volume, so it's not too hard
for me to give you other diffs like that, but the full output would be very very large and not
appropriate for posting here :)

Thanks,
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/