Re: [COMMAND HANGS] The command 'btrfs subvolume sync -s 2 xyz' can hangs.

From: Jeff Mahoney <jeffm@suse.com>
To: Giuseppe Della Bianca <giusdbg@gmail.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [COMMAND HANGS] The command 'btrfs subvolume sync -s 2 xyz' can hangs.
Date: Mon, 7 Jan 2019 17:40:19 -0500	[thread overview]
Message-ID: <1533b054-9d55-e968-74e2-b895de9e35fc@suse.com> (raw)
In-Reply-To: <2971657.kkKnYu9ILp@exnet.gdb.it>

[-- Attachment #1.1: Type: text/plain, Size: 2182 bytes --]

On 1/5/19 7:30 AM, Giuseppe Della Bianca wrote:
> In data venerdì 4 gennaio 2019 21:34:03 CET, Jeff Mahoney ha scritto:
> ]zac[
>>>
>>> root     17133 17127  0 17:17 ?        00:00:00 btrfs subvolume sync -s 2
>>> /
>>> tmp/tmp.p9SiQ1GnpV
>>>
>>> cat /proc/17133/stack
>>> [<0>] hrtimer_nanosleep+0xce/0x1e0
>>> [<0>] __x64_sys_nanosleep+0x77/0xa0
>>> [<0>] do_syscall_64+0x5b/0x160
>>> [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>> [<0>] 0xffffffffffffffff
>>
>> Ok, so this is it just sleeping between tree searches.
> ]zac[
>> This part is actually important since we see below that we're searching
>> for bytenr 76428623872 which, if present, would be in the cut portion of
>> your log.
> ]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.

> ]zac]
>>
>> This is the more important part.  The file system has gone read-only due
>> to a missing extent backref.  This is corruption.
> 
> Yes, but this is an autocorruption of btrfs, which occurred (it seems to me), 
> during a cleanup after a deleting of a snapshoot of an operating system 
> installation (perhaps interrupted by an umount).
> 
>> 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.

> The infinite wait occurs during the execution of a backup script, so I will 
> have to find a bypass even for this problem (the sync was a patch to another 
> autocorruption problem).

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
system is read-only.  That will cover the file system being taken
read-only due to failure, but is also general enough that it'll cover
the case where it can't possibly succeed.  For example, if the file
system is mounted read-only intentionally.

-Jeff
-- 
Jeff Mahoney
SUSE Labs

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]