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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Feb 16, 2014 at 5:23 PM, Marc MERLIN <marc@xxxxxxxxxxx> wrote:
> 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@xxxxxxxxxxx> 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?

Well, not much.
In the meanwhile I've found a way to reproduce the same issue, i.e.
send sending an rmdir operation for an orphan path that doesn't exist
anymore, which involves multiple hardlinks against same file in a
directory and deleting the directory. See the patch I just sent to the
list titled:  "[PATCH] Btrfs: send, don't send rmdir for same target
multiple times".

Maybe your issue is different, triggered under different conditions
and with different steps (no multiple hardlinks in the deleted
directory).

I'll see if I come up with other ways of getting into that issue.

thanks


>
> 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/



-- 
Filipe David Manana,

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."
--
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




[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux