linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Jeff Mahoney <jeffm@suse.com>,
	moparisthebest <admin@moparisthebest.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: btrfs kernel oops on mount
Date: Mon, 12 Sep 2016 08:54:50 -0400	[thread overview]
Message-ID: <84b8f928-48e3-00dc-1d16-fedb04f8d180@gmail.com> (raw)
In-Reply-To: <357b5b17-f84e-7f09-ad2d-c4700da0bf9c@suse.com>

On 2016-09-12 08:33, Jeff Mahoney wrote:
> On 9/9/16 8:47 PM, Austin S. Hemmelgarn wrote:
>> A couple of other things to comment about on this:
>> 1. 'can_overcommit' (the function that the Arch kernel choked on) is
>> from the memory management subsystem.  The fact that that's throwing a
>> null pointer says to me either your hardware has issues, or the Arch
>> kernel itself has problems (which would probably mean the kernel image
>> is corrupted).
>
> fs/btrfs/extent-tree.c:
> static int can_overcommit(struct btrfs_root *root,
>                           struct btrfs_space_info *space_info, u64 bytes,
>                           enum btrfs_reserve_flush_enum flush)
>
OK, my bad there, but that begs the question: why does a BTRFS function 
not have a BTRFS prefix?  The name blatantly sounds like a mm function 
(and I could have sworn I can across one with an almost identical name 
when I was trying to understand the mm code a couple months ago), and 
the lack of a prefix combined with that heavily implies that it's a core 
kernel function.

Given this, it's almost certainly the balance choking on corrupted 
metadata that's causing the issue.
>> 3. In general, it's a good idea to keep an eye on space usage on your
>> filesystems.  If it's getting to be more than about 95% full, you should
>> be looking at getting some more storage space.  This is especially true
>> for BTRFS, as a 100% full BTRFS filesystem functionally becomes
>> permanently read-only because there's nowhere for the copy-on-write
>> updates to write to.
>
> The entire point of having the global metadata reserve is to avoid that
> situation.
Except that the global metadata reserve is usually only just barely big 
enough, and it only works for metadata.  While I get that this issue is 
what it's supposed to fix, it doesn't do so in a way that makes it easy 
to get out of that situation.  The reserve itself is often not big 
enough to do anything in any reasonable amount of time once the FS gets 
beyond about a hundred GB and yous tart talking about very large files.

  reply	other threads:[~2016-09-12 12:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-09 16:12 btrfs kernel oops on mount moparisthebest
2016-09-09 17:51 ` Chris Murphy
2016-09-09 18:32   ` moparisthebest
2016-09-09 18:49     ` Austin S. Hemmelgarn
2016-09-09 19:21     ` Chris Murphy
2016-09-10 15:13   ` moparisthebest
2016-09-09 18:47 ` Austin S. Hemmelgarn
2016-09-09 19:23   ` moparisthebest
2016-09-09 22:09     ` Duncan
2016-09-12 11:37     ` Austin S. Hemmelgarn
2016-09-12 13:32       ` moparisthebest
2016-09-09 19:28   ` Chris Murphy
2016-09-10 18:50     ` moparisthebest
2016-09-12 12:33   ` Jeff Mahoney
2016-09-12 12:54     ` Austin S. Hemmelgarn [this message]
2016-09-12 13:27       ` Jeff Mahoney
2016-09-12 13:58         ` Austin S. Hemmelgarn

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=84b8f928-48e3-00dc-1d16-fedb04f8d180@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=admin@moparisthebest.com \
    --cc=jeffm@suse.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 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).