From: Josef Bacik <jbacik@fb.com>
To: Dan Merillat <dan.merillat@gmail.com>,
BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Rapid memory exhaustion during normal operation
Date: Wed, 29 Jan 2014 16:00:40 -0500 [thread overview]
Message-ID: <52E96BF8.3000601@fb.com> (raw)
In-Reply-To: <52E430F7.7030801@gmail.com>
On 01/25/2014 04:47 PM, Dan Merillat wrote:
> I'm trying to track this down - this started happening without changing the kernel in use, so probably
> a corrupted filesystem. The symptoms are that all memory is suddenly used by no apparent source. OOM
> killer is invoked on every task, still can't free up enough memory to continue.
>
> When it goes wrong, it's extremely rapid - system goes from stable to dead in less than 30 seconds.
>
> Tested 3.9.0, 3.12.0, 3.12.8. Limited testing on 3.13 shows I think the same problem but I need
> to double-check that it's not a different issue. Blows up the exact same way on a real kernel or in
> UML.
>
> All sorts of things can trigger it - defrag, random writes to files. Balance and scrub don't,
> readonly mount doesn't.
>
> I can reproduce this trivially, mount the filesystem read-write and perform some activity. It only
> takes a few minutes. The other btrfs filesystems on the same machine don't show similar problems.
> Unfortunately, the output of btrfs-image -c9 is 75gb, much more than I can reasonably share. I've got
> a reliable reproducer in UML using UML-COW to always start with the same base image, defrag a file with
> 33,000 extents and the system explodes within a minute.
>
> Here's the OOM report, the formatting is a bit off due to being delivered via netconsole.
> Swap was disabled on this run, but it makes no difference. I get insta-OOM issues out of the blue
> with very little memory swapped out.
Don't defrag right now, the snapshot aware defrag is horribly broken and
will OOM the box. Thanks,
Josef
next prev parent reply other threads:[~2014-01-29 21:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-25 21:47 Rapid memory exhaustion during normal operation Dan Merillat
2014-01-29 1:55 ` Duncan
2014-01-29 3:57 ` Chris Murphy
2014-01-29 6:23 ` Duncan
2014-01-29 21:00 ` Josef Bacik [this message]
2014-01-29 22:38 ` Imran Geriskovan
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=52E96BF8.3000601@fb.com \
--to=jbacik@fb.com \
--cc=dan.merillat@gmail.com \
--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.