linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jon Bernard <jbernard@tuxion.com>
To: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: linux-ext4@vger.kernel.org, Theodore Ts'o <tytso@mit.edu>
Subject: Re: kernel bug at fs/ext4/resize.c:409
Date: Thu, 13 Feb 2014 09:53:23 -0500	[thread overview]
Message-ID: <20140213145323.GA6296@helmut> (raw)
In-Reply-To: <87sirnp2m3.fsf@openvz.org>

* Dmitry Monakhov <dmonakhov@openvz.org> wrote:
> On Thu, 6 Feb 2014 16:08:44 -0500, Jon Bernard <jbernard@tuxion.com> wrote:
> Non-text part: multipart/mixed
> > * Theodore Ts'o <tytso@mit.edu> wrote:
> > > On Mon, Feb 03, 2014 at 01:26:34PM -0500, Jon Bernard wrote:
> > > > Hello all,
> > > > 
> > > > A coworker is seeing the following bug when attempting to resize a root
> > > > volume (during init by calling resizefs) from 1GB to the size of the
> > > > underlying partition size of 20GB.
> > > > 
> > > > If the partition size is changed (to i.e. 10GB), the bug seems to not
> > > > trigger.  I have access to this machine, if there are any experiments
> > > > that would provide more useful information - please let me know.
> > > 
> > > Here are three questions to start:
> > > 
> > > 1)  What kernel version was this oops coming from?
> > 
> > 3.12.9-301.fc20.x86_64
> > 
> > > 2)  Could you please send me the output of dumpe2fs of the file system?
> > 
> > Dump attached.
> > 
> > > 3)  Can you reproduce the problem?
> > 
> > It happens every time with this particular filesystem image.  A new
> > image built with slightly different variables (size, contents, etc)
> > usually yields a filesystem that behaves correctly.  But once they have
> > a bad one, it breaks on resize every time.
> > 
> > Let me know if I can provide any other information.  I have access to
> > the machine for some time, so I can run a modified kernel or module and
> > post results if that would help.
> > 
> > Thanks,
> > 
> Yepp..  same BUGON was recently triggered by one of our customers
> on ovzkernel kernel which is based on RHEL6's (2.6.32) kernel:
> Resize the image /vz/private/2345.private_temporary-XXXX/root.hdd to
> 536870912K
> resize2fs 1.42.3 (14-May-2012)
> Filesystem at /dev/ploop15153p1 is mounted on
> /vz/private/2345.private_temporary-XXXX/root.hdd/root.hds.mnt; on-line
> resizing required
> old_desc_blocks = 1, new_desc_blocks = 32
> <4>[ 1043.647040] ------------[ cut here ]------------
> <2>[ 1043.647067] kernel BUG at fs/ext4/resize.c:375!
> 
> But after that image was destroyed, and we can not reproduce this bug at
> the moment.
> 
> Can you please share image created via e2image and blkimage size:
> #e2image -r /dev/$YOUR_DEV - | bzip2 > img.e2i.bz2
> #blockdev --getsz /dev/$YOUR_DEV
> and resize2fs arguments.

The image should be available here:

http://c5a6e06e970802d5126f-8c6b900f6923cc24b844c506080778ec.r72.cf1.rackcdn.com/fedora_resize_fails.qcow2

The md5sum is: 267fd37e3a5e1c4d50bd133dd2835c98

-- 
Jon

  reply	other threads:[~2014-02-13 14:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-03 18:26 kernel bug at fs/ext4/resize.c:409 Jon Bernard
2014-02-03 18:56 ` Theodore Ts'o
2014-02-06 21:08   ` Jon Bernard
2014-02-13 13:24     ` Dmitry Monakhov
2014-02-13 14:53       ` Jon Bernard [this message]
2014-02-13 21:18         ` Theodore Ts'o
2014-02-13 21:27           ` Theodore Ts'o
2014-02-14  3:13           ` Andreas Dilger
2014-02-14 20:19           ` Jon Bernard
2014-02-14 23:46             ` Theodore Ts'o
2014-02-15  3:16               ` Darrick J. Wong
2014-02-15 15:34                 ` Theodore Ts'o
2014-02-16  2:35 ` [PATCH] ext4: fix online resize with very large inode tables Theodore Ts'o

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=20140213145323.GA6296@helmut \
    --to=jbernard@tuxion.com \
    --cc=dmonakhov@openvz.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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).