On 1/8/19 4:02 PM, Giuseppe Della Bianca wrote:
> In data lunedì 7 gennaio 2019 23:40:19 CET, Jeff Mahoney ha scritto:
> ]zac[
>>> If you want, I can send you the full log (very long).
>>> From what you wrote below it seems to me that you do not need it
>>
>> Please do.  It would be good to see what the state of the extent tree is
>> there.
> 
> 
> -- Logs begin at Sat 2016-11-26 18:16:29 CET, end at Tue 2019-01-08 21:39:44 

Thanks.  As it turns out, since Filipe's identified the fix for this
issue, we don't need it anymore.  If that turns out to be a different
issue, we can revisit the log.

> ]zac[
>>>> It also means that the subvolume is never going to disappear during this
>>>> mount and 'btrfs subvol sync' will wait forever.
>>>
>>> ]zac[
>>>
>>> In my opinion this is bad.
>>
>> Agreed.  I was describing what the situation is, not how it should be.
> 
> Ok, sorry ( :) ).
> 
> ]zac[
>> It's something that needs fixing.  The question is how to go about that.
>>  My first take on it is to have that loop also check whether the file
> ]zac[
> 
> I don't know how btrfs works inside.
> I just suppose that somewhere in the code an error state is not handled 
> correctly (which can be a file or the whole filesystem not accessible).

Kind of, if you look at it under the right light.  The sync subcommand
only waits for the lookup for the subvolume undergoing deletion to not
be there anymore.  There's no error state to be passed back to the
waiter, only the initiator.

The command will hang any time a situation arises that the subvolume
won't go away.  That includes:
1) Read-only file system, intentionally
2) Read-only file system as part of a failure
3) Specifying a subvolume that isn't being deleted

The first two mean that the condition can never be met.  The latter is
something of a special case since the user could remove it at any time.

-Jeff
-- 
Jeff Mahoney
SUSE Labs