All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Po-Hsu Lin <po-hsu.lin@canonical.com>, Jeff Mahoney <jeffm@suse.com>
Cc: Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: reproducable oops in btrfs/130 with latests mainline
Date: Fri, 20 Oct 2017 17:36:25 +0800	[thread overview]
Message-ID: <caa184aa-73ee-fd3a-2ac6-61de414567d4@gmx.com> (raw)
In-Reply-To: <CAMy_GT_fRoHtZtWZiH_nh9++tb+woXDi09K+Zn6PLp-aFmhRLA@mail.gmail.com>



On 2017年10月20日 17:25, Po-Hsu Lin wrote:
> Thanks for the info.
> 
> I have checked the comment inside the test case, which state that:
> # And unfortunately, btrfs send is one of these operations, and will cause
> # softlock or OOM on systems with small memory(<4G).
> 
> To my experience, this will stuck on a system with 32G memory too.

Sorry for the confusion, I mean softlock if you have enough memory.
And if you don't have enough memory, you will get an OOM.

> 
> And in the end of the script, it says:
> # send out the subvolume, and it will either:
> # 1) OOM since memory is allocated inside a O(n^3) loop
> # 2) Softlock since time consuming backref walk is called without scheduling.
> 
> I can see the soft lockup behaviour (I guess this is the second result
> listed above?) from dmesg as described in
> https://bugs.launchpad.net/bugs/1718925
> 
> So I'm curious that does anyone know how long it might take if this test works?

Just skip it, or make it dangerous.
(Which I should do it in the very beginning)

Thanks,
Qu

> Tried 8 hours as a timeout limit but no luck. Or maybe this test is
> totally broken?
> 
> Thanks!
> 
> On Tue, Oct 17, 2017 at 9:03 PM, Jeff Mahoney <jeffm@suse.com> wrote:
>> On 10/17/17 8:46 AM, Qu Wenruo wrote:
>>>
>>>
>>> On 2017年10月17日 19:11, Po-Hsu Lin wrote:
>>>> Hello Chris,
>>>>
>>>> I can reproduce this on my side too, with Ubuntu 16.04 + 4.4.0-97 kernel.
>>>
>>> Btrfs/130 is a known bug.
>>>
>>> I submitted it to raise the concern about such situation and purposed
>>> one possible solution (just disable deduped file detection).
>>>
>>> But the solution doesn't get accepted.
>>
>> It also works very well as a performance test for qgroup runtime
>> improvements. :)
>>
>> -Jeff
>>
>>> Thanks,
>>> Qu
>>>>
>>>> PREEMPT config:
>>>> $ cat config-4.4.0-97-generic | grep PREEMPT
>>>> CONFIG_PREEMPT_NOTIFIERS=y
>>>> # CONFIG_PREEMPT_NONE is not set
>>>> CONFIG_PREEMPT_VOLUNTARY=y
>>>> # CONFIG_PREEMPT is not set
>>>>
>>>> Bug reports on launchpad:
>>>> https://bugs.launchpad.net/bugs/1718925
>>>> https://bugs.launchpad.net/bugs/1717443
>>>> --
>>>> 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
>>>>
>>>
>>
>>
>> --
>> Jeff Mahoney
>> SUSE Labs
>>
> --
> 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
> 

      reply	other threads:[~2017-10-20  9:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-14 12:35 reproducable oops in btrfs/130 with latests mainline Christoph Hellwig
2016-11-25  8:07 ` Christoph Hellwig
2016-11-26 17:23   ` Chris Mason
     [not found]   ` <190cc125&#45;d1c1&#45;6005&#45;c23b&#45;cc54c825f242@fb.com>
2017-10-17 11:11     ` Po-Hsu Lin
2017-10-17 12:46       ` Qu Wenruo
2017-10-17 13:03         ` Jeff Mahoney
2017-10-20  9:25           ` Po-Hsu Lin
2017-10-20  9:36             ` Qu Wenruo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=caa184aa-73ee-fd3a-2ac6-61de414567d4@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=jeffm@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=po-hsu.lin@canonical.com \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.