From: Olivier Bonvalet <btrfs.list@daevel.fr>
To: linux-btrfs@vger.kernel.org
Subject: Re: [solved] Re: Frozen transaction
Date: Tue, 09 Oct 2012 16:12:54 +0200 [thread overview]
Message-ID: <507430E6.8040107@daevel.fr> (raw)
In-Reply-To: <20121009140716.GQ4405@twin.jikos.cz>
On 09/10/2012 16:07, David Sterba wrote:
> On Tue, Oct 09, 2012 at 03:49:01PM +0200, Olivier Bonvalet wrote:
>> On 09/10/2012 14:32, David Sterba wrote:
>>> On Tue, Oct 09, 2012 at 12:07:20PM +0200, Olivier Bonvalet wrote:
>>>> I didn't see any "stack" entry in /proc/$PID/ ; I will try to find which
>>>> kernel option export that.
>>>
>>> CONFIG_STACKTRACE
>>
>> CONFIG_STACKTRACE_SUPPORT=y
>> CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
>> CONFIG_CC_STACKPROTECTOR=y
>> # CONFIG_DEBUG_STACK_USAGE is not set
>> CONFIG_USER_STACKTRACE_SUPPORT=y
>> # CONFIG_DEBUG_STACKOVERFLOW is not set
>>
>> I suppose it's CONFIG_DEBUG_STACK_USAGE ?
>
> I looked into the sources which config option enables the /proc/./stack
> output, but I don't know which one is it in the menuconfig.
>
Ok, I will search for that, thanks.
>> Well... I don't know if it is related to that space cache, but the cleanup
>> process is now working : it makes a lot of write requests, and I have now
>> 30Go of free space. So it will be solved soon.
>
> Great, looks like it was able to do some progress and free more space
> for further work.
>
>> Any chance that it can be related to that space cache feature ?
>
> The problem is that if the space is tight, it slows down operations that
> depend on it. I've seen very slow snapshot cleaning in similar
> situation, free-space was constantly working. So it is related, but also
> expected and IMHO unavoidable.
>
What I didn't understand, is that since 24 hours, there was near 0 IO
request done on that device. The cleanup processes was just «frozen»,
not doing anything visible (no CPU and no IO) ; like a deadlock.
>>> Probably no, although if you're fast enough and add another device before
>>> the cleaner starts, it could work :)
>>
>> Ho it's possible, it's a virtualized system, so the device can easily grow.
>
> That makes a difference of course :)
>
>> I was starting to patch my kernel before to see it's now solved.
>
>
> Glad to hear that,
> david
>
next prev parent reply other threads:[~2012-10-09 14:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-09 7:37 Frozen transaction Olivier Bonvalet
2012-10-09 9:52 ` David Sterba
2012-10-09 10:07 ` Olivier Bonvalet
2012-10-09 12:32 ` David Sterba
2012-10-09 13:49 ` [solved] " Olivier Bonvalet
2012-10-09 14:07 ` David Sterba
2012-10-09 14:12 ` Olivier Bonvalet [this message]
2012-10-09 14:55 ` David Sterba
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=507430E6.8040107@daevel.fr \
--to=btrfs.list@daevel.fr \
--cc=linux-btrfs@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).