All of lore.kernel.org
 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 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.