All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <Martin@lichtvoll.de>
To: linux-btrfs@vger.kernel.org
Cc: Dave Jones <davej@redhat.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: btrfs crash when low on memory.
Date: Wed, 27 Feb 2013 11:28:05 +0100	[thread overview]
Message-ID: <201302271128.05815.Martin@lichtvoll.de> (raw)
In-Reply-To: <20130227052247.GA20213@redhat.com>

Am Mittwoch, 27. Februar 2013 schrieb Dave Jones:
> Something I've yet to repeat managed to leak a whole bunch of memory
> while I was travelling, and locked up my workstation.
> 
> When I got home, this was the last thing printed out before it locked up
> (it did make it into the logs thankfully) after a bunch of instances of
> the oom-killers handywork.
> 
> 
> 
> SLUB: Unable to allocate memory on node -1 (gfp=0x50)
>   cache: btrfs_extent_state, object size: 176, buffer size: 504, default
> order: 1, min order: 0 node 0: slabs: 49, objs: 640, free: 0
> ------------[ cut here ]------------
> kernel BUG at fs/btrfs/extent_io.c:748!

Thank you for reporting this Dave.

I have lockups due to memory pressure conditions on my ThinkPad T520 as well 
when playing Planeshift for some time. (AFAIR since I switched my home 
directory to BTRFS (/ was BTRFS before), but I am not sure about this.) 
Planeshift goes from 2 GB to about 4 GB RSS and then the machine usually 
starts to swap to SSD. 

I did not get around to report this yet. The machine is basically locked (at 
least for long periods of times like minutes). I intend to collect some 
photos and upload them somewhere, cause I do not see anything in logs after 
reboot.

I think this happens *before* real OOM conditions are met (i.e. all of swap 
is being used up as well).

In backtraces btrfs related stuff appears.

Expected results of cause: System continues swapping and if OOM conditions 
are met calls the OOM killer (which might try to get rid of running 
Planeshift client).

Current workaround: Develop a good feeling on when to better restart the PS 
client. :)

So for now just a heads up that I have seen similar issues. (But I think my 
backtraces might have been different, difficult to say since some of it 
scrolls by quite quickly.)

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

  reply	other threads:[~2013-02-27 10:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-27  5:22 btrfs crash when low on memory Dave Jones
2013-02-27 10:28 ` Martin Steigerwald [this message]
2013-02-27 13:27 ` Josef Bacik
2013-02-27 14:31   ` Ahmet Inan
2013-02-27 18:26     ` Josef Bacik
2013-02-27 20:10       ` Ahmet Inan
2013-02-27 21:11         ` Josef Bacik
2013-02-27 21:20           ` Ahmet Inan
2013-03-04 22:07     ` Martin Steigerwald

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=201302271128.05815.Martin@lichtvoll.de \
    --to=martin@lichtvoll.de \
    --cc=davej@redhat.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@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.