[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-btrfs
Subject:    Problems with incremental btrfs send (out of order instructions?)
From:       Mathijs Kwik <mathijs () bluescreen303 ! nl>
Date:       2013-07-31 21:33:59
Message-ID: CAKvOHKD+cYp+CO4XLXkktnFZ_5n1tZnbrqS3D+T8nJhVEReWig () mail ! gmail ! com
[Download RAW message or body]

Hi all,

For some time, I've successfully deployed btrfs send/receive as a
viable backup solution.
It's fast and flexible and nicely scriptable =)
However, every once in a while, trouble strikes on the receiving end
with a message like:

ERROR: rename nixpkgs/pkgs/applications/version-management/subversion-1.2.x/default.nix
-> o2979-81788-0 failed. No such file or directory

Judging from looking at the dump-stream, I think sometimes a directory
gets moved (subversion-1.2.x in the example) to some temporary name
(or it gets deleted), but a little later a file within that directory
is being changed.
This seems to happen most often with filesystem-heavy applications
like a git tree or a webbrowser's cache dir.

I've tried many things to recover from such a situation, like removing
the offending directory and retrying from a new snapshot, but nothing
seems to work except for a full (non-incremental) send which is
expensive.

After some narrowing down, I managed to capture a problematic
sendstream. To reproduce:
- I created a separate subvolume (so there are no privacy-related
issues with sharing the dump)
- put a moderately large git tree on it (I used
https://github.com/NixOS/nixpkgs)
- perform an initial btrfs send of the subvolume
- jump around git history (check out very early revision, check out HEAD again)
- perform an incremental (with parent) btrfs send to a file
- try to receive this file on another machine
- about 80% chance this triggers it, if not, jump/branch some more with git

The problematic dump is here:
https://bluescreen303.nl/btrfs-send-error.dump.xz
The error provided above goes with this dump.

The dump was on kernel 3.9.x but it still happens on 3.10.4
btrfs-progs 650e656a8b9c1fbe4ec5cd8c48ae285b8abd3b69
I noticed there have been some commits since that revision but nothing
mentions send/receive.

Can someone have a look at my dumpfile and confirm this is indeed a
problem with btrfs send as opposed to something I am doing wrong?

Thanks!
Mathijs
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]