Message-ID: <CAGBYx2bWQekPEasXAK9cYrisTdo+Cp0d7sZYnmv_rjFy7rEv5g@mail.gmail.com>
Date:	Fri, 30 Dec 2011 22:37:57 +0800
From:	Yongqiang Yang <xiaoqiangnk@...il.com>
To:	"Ted Ts'o" <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH v5 00/15] ext4: add new online resize

Hi Ted,

Sorry for my carelessness.   I updated the patch and wrote a
regression test as you suggested which is put on my github
https://github.com/YANGYongqiang/ext4-online-resize-regression-tests.
The latest patch passed the regression test.

Yongqiang.
On Thu, Dec 29, 2011 at 12:07 PM, Ted Ts'o <tytso@....edu> wrote:
> Hi,
>
> FYI, I just updated the online resizes in the unstable portion of the
> ext4 series to the V5 version.  Unfortunately, I was able to trigger a
> BUG_ON at line 497 of resize.c trying to resize a simple ext3 file
> system.  (See below)
>
> I'd suggest that you use a regression test suite that tries a various
> different mke2fs commands with -t ext3, -t ext4, as well as different
> file system options (i.e., -t ext3 -O extents, -t ext4 -O bigalloc,
> etc.)  Also make sure you try different sizes so that you we check
> extending a flex_bg, growing a new flex_bg, etc.
Ok.  I know what happened.

>
> In this particular case, the problem is that the resize code appears
> to assume the uninit_bg file system feature aka
> EXT4_FEATURE_RO_COMPAT_GDT_CSUM is always going to be set.
>
>                                          - Ted
>
> # grep vdc /proc/partitions
>  254       32    5242880 vdc
> # mke2fs -t ext3 /dev/vdc 512M
> # mount /dev/vdc
> # resize2fs /dev/vdc
> resize2fs 1.42-WIP (16-Oct-2011)
> Filesystem at /dev/vdc is mounted on /vdc; on-line resizing required
> old_desc_blocks = 1, new_desc_blocks = 1
> [  187.749591] ------------[ cut here ]------------
> [  187.751725] kernel BUG at /usr/projects/linux/ext4/fs/ext4/resize.c:497!
> [  187.752756] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
> [  187.752756] Modules linked in:
> [  187.752756]
> [  187.752756] Pid: 2204, comm: resize2fs Not tainted 3.2.0-rc6-00030-g82a1181 #46 Bochs Bochs
> [  187.752756] EIP: 0060:[<c035281a>] EFLAGS: 00010202 CPU: 0
> [  187.752756] EIP is at setup_new_flex_group_blocks+0x33f/0x6d2
> [  187.752756] EAX: 00000001 EBX: f6297000 ECX: 00570a4a EDX: 00000000
> [  187.752756] ESI: 00000000 EDI: 00000001 EBP: f62f3d8c ESP: f62f3d0c
> [  187.752756]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
> [  187.752756] Process resize2fs (pid: 2204, ti=f62f2000 task=f5eca940 task.ti=f62f2000)
> [  187.752756] Stack:
> [  187.752756]  c01ce2dc f6824ee0 00000020 0000001f 00000000 00000004 f6a2d778 f6297000
> [  187.752756]  00020001 00000000 00000000 00000000 f6297c00 f62f3d6c f37877c0 00000004
> [  187.752756]  f6ab9c30 f37877c0 00000000 f6824f2c 00020001 00000000 f6415168 c020b5a0
> [  187.752756] Call Trace:
> [  187.752756]  [<c01ce2dc>] ? trace_hardirqs_on_caller+0x10f/0x140
> [  187.752756]  [<c020b5a0>] ? __delayacct_blkio_end+0x55/0x5b
> [  187.752756]  [<c03534d4>] ext4_flex_group_add+0xc2/0x10c6
> [  187.752756]  [<c0a33706>] ? __wait_on_bit+0x6e/0x77
> [  187.752756]  [<c02bfcf5>] ? unmap_underlying_metadata+0x5d/0x5d
> [  187.752756]  [<c02bfcf5>] ? unmap_underlying_metadata+0x5d/0x5d
> [  187.752756]  [<c02847ec>] ? trace_kmalloc+0x2f/0x95
> [  187.752756]  [<c035489d>] ? ext4_resize_fs+0x3c5/0xb56
> [  187.752756]  [<c0284ca5>] ? __kmalloc+0x20d/0x219
> [  187.752756]  [<c035489d>] ? ext4_resize_fs+0x3c5/0xb56
> [  187.752756]  [<c0354d33>] ext4_resize_fs+0x85b/0xb56
> [  187.752756]  [<c01cf1df>] ? lock_release_non_nested+0xb5/0x1e8
> [  187.752756]  [<c03343a7>] ext4_ioctl+0xbcf/0xda4
> [  187.752756]  [<c01bc804>] ? sched_clock_cpu+0x22e/0x23e
> [  187.752756]  [<c01cba23>] ? trace_hardirqs_off+0xb/0xd
> [  187.752756]  [<c0282f25>] ? slab_free_hook+0x5e/0x6b
> [  187.752756]  [<c029d5e6>] vfs_ioctl+0x4a/0x78
> [  187.752756]  [<c029ddf5>] do_vfs_ioctl+0x66d/0x67f
> [  187.752756]  [<c0284725>] ? kmem_cache_free+0xe8/0x144
> [  187.752756]  [<c02988b5>] ? putname+0x62/0x66
> [  187.752756]  [<c02988b5>] ? putname+0x62/0x66
> [  187.752756]  [<c028727e>] ? do_sys_open+0x12c/0x136
> [  187.752756]  [<c029de7b>] sys_ioctl+0x74/0xaa
> [  187.752756]  [<c0a3600d>] syscall_call+0x7/0xb
> [  187.752756] Code: 83 e0 05 48 0f 95 c0 31 c9 0f b6 f8 b8 64 11 04 c1 89 fa e8 14 05 ed ff 8b 04 bd c8 6e 12 c1 40 85 ff 89 04 bd c8 6e 12 c1 74 04 <0f> 0b eb fe 8b 55 98 8b 7d c8 0f b7 04 7a d1 e8 83 e0 01 8b 14
> [  187.752756] EIP: [<c035281a>] setup_new_flex_group_blocks+0x33f/0x6d2 SS:ESP 0068:f62f3d0c
> [  187.822687] ---[ end trace aa45447d850e7921 ]---
> Segmentation fault
>
>                                                - Ted
>
>
> On Fri, Dec 23, 2011 at 04:14:50PM +0800, Yongqiang Yang wrote:
>> Hi all,
>>
>> This is the 5th version of patch series adding new online resize to ext4.
>>
>> -- What's new resize implementation?
>>    It is a new online resize interface for ext4.  It can be used via
>>    ioctl with EXT4_IOC_RESIZE_FS and a 64 bit integer indicating size
>>    of the resized fs in block.
>>
>> -- Difference between current resize and new resize.
>>    New resize lets kernel do all work, like allocating bitmaps and
>>    inode tables and can support flex_bg and BLOCK_UNINIT features.
>>    Besides these, new resize is much faster than current resize.
>>
>>    Below are benchmarks I made on my personal computer, fses with
>>    flex_bg size = 16 were resized to 230GB evry time. The first
>>    row shows the size of a fs from which the fs was resized to 230GB.
>>    The datas were collected by 'time resize2fs'.
>>
>>                       new resize
>>                 20GB          50GB      100GB
>>       real    0m3.558s     0m2.891s    0m0.394s
>>       user    0m0.004s     0m0.000s    0m0.394s
>>       sys     0m0.048s     0m0.048s    0m0.028s
>>
>>                       current resize
>>                 20GB          50GB      100GB
>>       real    5m2.770s     4m43.757s  3m14.840s
>>       user    0m0.040s     0m0.032s   0m0.024s
>>       sys     0m0.464s     0m0.432s   0m0.324s
>>
>>    According to data above, new resize is faster than current resize in both
>>    user and sys time.  New resize performs well in sys time, because it
>>    supports BLOCK_UNINIT and adds multi-groups each time.
>>
>> -- About supporting new features.
>>    YES! New resize can support new feature like bigalloc and exclude bitmap
>>    easily.  Because it lets kernel do all work.
>>
>>  V4->V5:
>>    release resizing lock in error case of IOC_RESIZEFS
>>    Thanks Djalal <tixxdz@...ndz.org> for pointing it out and his patch for
>>    IOC_GROUP_EXTEND and IOC_GROUP_ADD.
>>
>>  V3->V4:
>>    rename __ext4_group_extend to ext4_group_extend_no_check.
>>
>>  V2->V3:
>>    initialize block bitmap of last group.
>>    remove code initalizing inode bitmap and inode tables.
>>
>> Yongqiang.
>>



-- 
Best Wishes
Yongqiang Yang
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists