Re: kernel trace, (nearly) every time on send/receive

[Anand Jain <anand.jain@oracle.com>]

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
>