* Dmitry Monakhov <dmonakhov@xxxxxxxxxx> wrote: > On Thu, 6 Feb 2014 16:08:44 -0500, Jon Bernard <jbernard@xxxxxxxxxx> wrote: > Non-text part: multipart/mixed > > * Theodore Ts'o <tytso@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
