From: Anssi Hannula <anssi.hannula@iki.fi>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Yongqiang Yang <xiaoqiangnk@gmail.com>,
Kevin Liao <kevinlia@gmail.com>,
Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 2/2] resize2fs: fix overhead calculation for meta_bg file systems
Date: Tue, 04 Sep 2012 20:05:26 +0300 [thread overview]
Message-ID: <504634D6.20608@iki.fi> (raw)
In-Reply-To: <20120904021412.GG5066@thunk.org>
04.09.2012 05:14, Theodore Ts'o kirjoitti:
> On Tue, Sep 04, 2012 at 09:59:55AM +0800, Yongqiang Yang wrote:
>> Hi Kevin,
>>
>> Ted has sent out the patches on online resizing for meta_bg and
>> 64bits, so you can have a try again. It seems that the bug in
>> e2fsprogs has been fixed.
>
> Make sure you use the latest version of the kernel patches that I just
> sent out. There quite a number of bugs in the Yongqiang's original
> patch set which I tripped over while I was testing 64-bit resize ---
> and please note that there are definitely still rough edges
> (especially for in cases where the file system was created < 16TB, but
> with the 64-bit feature and resize_inode features enabled). There may
> also be bugs for the straightforward case of resizing very large file
> systems.
Indeed, I hit a BUG_ON() on resize from 8589934590 blocks to 8589934640
blocks (4k):
[ 676.140165] ------------[ cut here ]------------
[ 676.150026] kernel BUG at fs/ext4/resize.c:255!
[ 676.150026] invalid opcode: 0000 [#1] SMP
[ 676.150026] CPU 0
[ 676.150026] Modules linked in:[ 676.150026] dm_snapshot dm_zero
af_packet dm_mod joydev hid_generic ppdev snd_intel8x0 snd_ac97_codec
ac97_bus usbhid microcode e1000 snd_pcm snd_page_alloc snd_timer hid
i2c_piix4 i2c_core button snd soundcore ac parport_pc parport processor
evdev ipv6 autofs4 ext4 crc16 jbd2 ohci_hcd sd_mod crc_t10dif usbcore
usb_common sr_mod ata_piix ahci libahci libata scsi_mod [last unloaded:
nf_defrag_ipv4]
[ 676.150026] Pid: 1793, comm: resize2fs Not tainted
3.5.3-server-2anssi.9.ext4.10.2 #1 innotek GmbH VirtualBox
[ 676.150026] RIP: 0010:[<ffffffffa014e9bc>] [<ffffffffa014e9bc>]
ext4_resize_fs+0x94c/0xa30 [ext4]
[ 676.150026] RSP: 0018:ffff880046eedd18 EFLAGS: 00010246
[ 676.150026] RAX: 0000000000040001 RBX: ffff88005b799800 RCX:
0000000000000001
[ 676.150026] RDX: 0000000000081bf1 RSI: 0000000000040001 RDI:
ffff88005b068000
[ 676.150026] RBP: ffff880046eeddd8 R08: 0000000200000003 R09:
0000000000000000
[ 676.150026] R10: 0000000000000000 R11: 0000000080042000 R12:
0000000000040001
[ 676.150026] R13: ffff880037fb5e20 R14: 0000000000000000 R15:
ffff88005b068000
[ 676.150026] FS: 00007fb43e067740(0000) GS:ffff88005fc00000(0000)
knlGS:0000000000000000
[ 676.150026] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 676.150026] CR2: 00007fd905261178 CR3: 0000000044993000 CR4:
00000000000006f0
[ 676.150026] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 676.150026] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[ 676.150026] Process resize2fs (pid: 1793, threadinfo
ffff880046eec000, task ffff880053f824c0)
[ 676.150026] Stack:
[ 676.150026] ffff880046eedda8 ffffffff8117971e 0000000f53529c40
0000000000000000
[ 676.150026] 000000020000002f 0000000000000000 0000000200000030
ffff88005b20e990
[ 676.150026] 0000000100000001 ffff880000000001 0000000200000000
0000000200000000
[ 676.150026] Call Trace:
[ 676.150026] [<ffffffff8117971e>] ? do_last+0x2ee/0x9f0
[ 676.150026] [<ffffffffa012e05f>] ext4_ioctl+0x9af/0xbc0 [ext4]
[ 676.150026] [<ffffffff8117db6f>] do_vfs_ioctl+0x8f/0x4e0
[ 676.150026] [<ffffffff8117e051>] sys_ioctl+0x91/0xa0
[ 676.150026] [<ffffffff8147d0bd>] system_call_fastpath+0x1a/0x1f
[ 676.150026] Code: c7 c1 60 2c 17 a0 ba 0c 07 00 00 48 c7 c6 9b e8 16
a0 4c 89 e7 31 c0 e8 b3 80 ff ff c7 85 6c ff ff ff ea ff ff ff e9 4c f8
ff ff <0f> 0b 8b 55 a4 8b 45 a0 f7 da 44 31 e0 85 c2 0f 84 6c fb ff ff
[ 676.150026] RIP [<ffffffffa014e9bc>] ext4_resize_fs+0x94c/0xa30 [ext4]
[ 676.150026] RSP <ffff880046eedd18>
[ 676.788513] ---[ end trace fbf2bd5a59c2ab99 ]---
This is BUG_ON(src_group >= group_data[0].group + flex_gd->count);
I was using the below basic test script which uses a virtual large
volume in LVM (e2fsprogs is 1.42.5, except for resize2fs):
#!/bin/bash -ex
VG=delta
LV=ext4test
LVSIZE=40T
MOUNTPOINT="/mnt/iso"
RESIZE2FS=/root/resize2fs
INITIAL_SIZE_K=4294967295
NEW_BLOCKS=8589934590
lvcreate -l 100%FREE -V "$LVSIZE" -n "$LV" "$VG"
mkfs.ext4 -O meta_bg,64bit,^resize_inode "/dev/$VG/$LV" "$INITIAL_SIZE_K"
mount "/dev/$VG/$LV" "$MOUNTPOINT"
mkdir "$MOUNTPOINT/test"
for file in 1 2; do
dd if=/dev/urandom bs=1M count=50 of="$MOUNTPOINT/test/$file"
done
md5sum $MOUNTPOINT/test/* > $MOUNTPOINT/MD5SUM
for N in $NEW_BLOCKS $((NEW_BLOCKS + 50)); do
$RESIZE2FS "/dev/$VG/$LV" "$N"
umount "$MOUNTPOINT"
fsck.ext4 -nvf "/dev/$VG/$LV"
mount "/dev/$VG/$LV" "$MOUNTPOINT"
md5sum -c "$MOUNTPOINT/MD5SUM"
done
> So while I very much appreciate users giving the code a try and
> sending us feedback, please do think twice before using this code on
> file systems with data that hasn't been backed up recently. (Of
> course, being good System Administrators you are all keeping --- and
> verifying --- regular backups, right? :-)
--
Anssi Hannula
next prev parent reply other threads:[~2012-09-04 17:20 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-02 9:52 [PATCH] resize2fs: support online-resizing for meta_bg and 64bits features Yongqiang Yang
2012-09-02 10:31 ` Yongqiang Yang
2012-09-03 0:50 ` Theodore Ts'o
2012-09-03 16:45 ` Theodore Ts'o
2012-09-03 16:45 ` [PATCH 1/2] resize2fs: allow meta_bg/64-bit file systems to be online resized Theodore Ts'o
2012-09-03 16:45 ` [PATCH 2/2] resize2fs: fix overhead calculation for meta_bg file systems Theodore Ts'o
2012-09-04 1:59 ` Yongqiang Yang
2012-09-04 2:14 ` Kevin Liao
2012-09-04 2:14 ` Theodore Ts'o
2012-09-04 17:05 ` Anssi Hannula [this message]
2012-09-05 2:10 ` Yongqiang Yang
2012-09-05 4:55 ` Theodore Ts'o
2012-09-05 5:16 ` Yongqiang Yang
2012-09-05 5:38 ` Theodore Ts'o
2012-09-06 14:22 ` Anssi Hannula
2012-09-06 16:19 ` Yongqiang Yang
2012-09-05 6:32 ` Kevin Liao
2012-09-05 6:44 ` Yongqiang Yang
2012-09-05 6:50 ` Kevin Liao
2012-09-13 23:21 ` Theodore Ts'o
2012-09-14 3:24 ` Kevin Liao
2012-09-04 2:02 ` Yongqiang Yang
2012-09-03 21:02 ` [PATCH] resize2fs: support online-resizing for meta_bg and 64bits features Kai Grosshaus
2012-09-03 23:00 ` Theodore Ts'o
2012-09-03 23:33 ` Kai Großhaus
2012-09-04 2:01 ` Yongqiang Yang
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=504634D6.20608@iki.fi \
--to=anssi.hannula@iki.fi \
--cc=kevinlia@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=xiaoqiangnk@gmail.com \
/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).