From: Theodore Ts'o <tytso@mit.edu>
To: Wilmer van der Gaast <wilmer@gaast.net>
Cc: Ben Hutchings <ben@decadent.org.uk>,
linux-ext4@vger.kernel.org, 692104@bugs.debian.org
Subject: Re: Bug#692104: linux-image-3.2.0-3-amd64: NULL pointer dereference in ext4fs
Date: Thu, 8 Nov 2012 10:30:48 -0500 [thread overview]
Message-ID: <20121108153048.GA32709@thunk.org> (raw)
In-Reply-To: <509440A3.5020604@gaast.net>
On Fri, Nov 02, 2012 at 10:52:35PM +0100, Wilmer van der Gaast wrote:
> >
> Oh yes, definitely. Sorry for not being clear.
>
> Also, this has just happened again. This time, after me not having
> touched the laptop for over ten hours. I'm starting to wonder
> whether my filesystem is corrupted. I'll make an LVM snapshot and
> then do a full fsck.
Did you perform another on-line resize on the file system before it
failed?
It looks like a problem which I ran into (and fixed) when adding
support for online resizing for > 16TB file systems, but I was pretty
sure it couldn't happen with until we added support for resizing very
large file systems using the new meta_bg resizing scheme. The commit
where I cleaned this up (but which was not backported to stable
kernels since it was part of a new feature and I didn't think it could
be triggered w/o the new feature) was:
commit 28623c2f5b0dca3c3ea34fd6108940661352e276
Author: Theodore Ts'o <tytso@mit.edu>
Date: Wed Sep 5 01:31:50 2012 -0400
ext4: grow the s_group_info array as needed
Previously we allocated the s_group_info array with enough space for
any future possible growth of the file system via online resize. This
is unfortunate because it wastes memory, and it doesn't work for the
meta_bg scheme, since there is no limit based on the number of
reserved gdt blocks. So add the code to grow the s_group_info array
as needed.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
How big was the file system before the resize, and how much larger did
you resize it? If it is this bug, the s_group_info array is allocated
based on the file system size when the file system is mounted. So it
would only be happening after a online resize and before the file
system is unmounted and/or the system is rebooted and the file system
is mounted again.
- Ted
next prev parent reply other threads:[~2012-11-08 22:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <50938953.6010001@gaast.net>
2012-11-02 14:33 ` Bug#692104: linux-image-3.2.0-3-amd64: NULL pointer dereference in ext4fs Ben Hutchings
2012-11-02 21:52 ` Wilmer van der Gaast
2012-11-08 15:30 ` Theodore Ts'o [this message]
2012-11-08 22:25 ` Wilmer van der Gaast
2012-11-24 0:00 ` Wilmer van der Gaast
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=20121108153048.GA32709@thunk.org \
--to=tytso@mit.edu \
--cc=692104@bugs.debian.org \
--cc=ben@decadent.org.uk \
--cc=linux-ext4@vger.kernel.org \
--cc=wilmer@gaast.net \
/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).