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 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.