On 2/12/19 11:30 AM, Christoph Anton Mitterer wrote:
Hey Anand.
Thanks for looking into this.
On Mon, 2019-12-02 at 10:58 +0800, Anand Jain wrote:
Looks like ORPHAN_CLEANUP_DONE is not set on the root.
WARN_ON(send_root->orphan_cleanup_state !=
ORPHAN_CLEANUP_DONE);
ORPHAN_CLEANUP_DONE is set unless it is a readonly FS, which I doubt
is,
(can be checked using btrfs inspect duper-super <dev>) because you
are
creating the snapshot for the send.
I should perhaps add, that there are two btrfs filesystems involved
here:
The first is basically the master, having several snapshots including
all + one newer which is missing from the second (which is basically a
backup of the master).
So it's about:
/master# btrfs send -p already-on-copy newer-snapshot | btrfs receive /copy/snapshots/ ;
In fact /master is mounted ro only here, whereas /copy is of course
mounted rw.
Since nothing should be changed on /master I assumed it would be ok to
have it mounted ro.
I am able to reproduce. Create send from the readonly mounted FS
and we log the warning as we couldn't clean the orphan flag. It's
false positive log. Will fix.
As of now there is nothing that tells me the FS at your end would
need a btrfs check so please ignore that part.
One question though - why the FS is readonly mounted? Its ok if that's
part of your operations.
Thanks, Anand
btrfs check --readonly might tell
us more about the issue.
I cannot do this right now since I'll be on some diving vacation for ~2
weeks,... but since --readonly is the standard behaviour (i.e. same
without --readonly) I'm pretty sure that a fsck (which I always do
after each snapshot to the /copy) brought now visible errors.
Does the whole thing imply any corruption to any of the two
filesystems... or is it just a "cosmetic" issue?
Cheers,
Chris
