* kernel bug at fs/ext4/resize.c:409
@ 2014-02-03 18:26 Jon Bernard
2014-02-03 18:56 ` Theodore Ts'o
2014-02-16 2:35 ` [PATCH] ext4: fix online resize with very large inode tables Theodore Ts'o
0 siblings, 2 replies; 13+ messages in thread
From: Jon Bernard @ 2014-02-03 18:26 UTC (permalink / raw)
To: linux-ext4
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.
[ 112.136896] ext4-fs (sda1): resizing filesystem from 1080688 to 5243214 blocs
[ 112.164072] ------------[ cut here ]------------
[ 112.164179] kernel bug at fs/ext4/resize.c:409!
[ 112.164285] invalid opcode: 0000 [#1] smp
[ 112.164488] modules linked in: openvswitch vxlan ip_tunnel gre libcrc32c noui
[ 112.165042] cpu: 0 pid: 968 comm: resize2fs tainted: g i 3.12.9-301
[ 112.165042] hardware name: dell inc. optiplex 760 /0m858n, b9
[ 112.165042] task: ffff8800b7969080 ti: ffff8800b74f4000 task.ti: ffff8800b740
[ 112.165042] rip: 0010:[<ffffffff81254fa1>] [<ffffffff81254fa1>] set_flexbg_0
[ 112.165042] rsp: 0018:ffff8800b74f5c28 eflags: 00010216
[ 112.165042] rax: ffff8800b743bf00 rbx: ffff88007fae9000 rcx: 0000000000001000
[ 112.165042] rdx: ffff88007f4e2c00 rsi: 0000000000000001 rdi: 0000000000000010
[ 112.165042] rbp: ffff8800b74f5c70 r08: ffff8800afd27750 r09: ffff8800b7daee00
[ 112.165042] r10: 0000000000000000 r11: ffff8800afd27750 r12: 0000000000188000
[ 112.165042] r13: 0000000000000010 r14: 0000000000188000 r15: ffff8800b743b800
[ 112.165042] fs: 00007f858a7f4780(0000) gs:ffff8800be800000(0000) knlgs:00000
[ 112.165042] cs: 0010 ds: 0000 es: 0000 cr0: 000000008005003b
[ 112.165042] cr2: 00007f8589c1eea6 cr3: 00000000b7979000 cr4: 00000000000407f0
[ 112.165042] stack:
[ 112.165042] ffff8800afd27750 ffff8800b96cb060 ffff880000188000 000000108125b
[ 112.165042] 0000000000000010 ffff88007f4e2ed0 00000000000007ff ffff8800b7430
[ 112.165042] ffff8800b743b800 ffff8800b74f5d68 ffffffff81256768 0000000000180
[ 112.165042] call trace:
[ 112.165042] [<ffffffff81256768>] ext4_flex_group_add+0x1448/0x1830
[ 112.165042] [<ffffffff81257de2>] ext4_resize_fs+0x7b2/0xe80
[ 112.165042] [<ffffffff8123ac50>] ext4_ioctl+0xbf0/0xf00
[ 112.165042] [<ffffffff811c111d>] do_vfs_ioctl+0x2dd/0x4b0
[ 112.165042] [<ffffffff811b9df2>] ? final_putname+0x22/0x50
[ 112.165042] [<ffffffff811c1371>] sys_ioctl+0x81/0xa0
[ 112.165042] [<ffffffff81676aa9>] system_call_fastpath+0x16/0x1b
[ 112.165042] code: c8 4c 89 df e8 41 96 f8 ff 44 89 e8 49 01 c4 44 29 6d d4 0
[ 112.165042] rip [<ffffffff81254fa1>] set_flexbg_block_bitmap+0x171/0x180
[ 112.165042] rsp <ffff8800b74f5c28>
[ 112.175633] ---[ end trace f179f994a575df06 ]---
--
Jon
^ permalink raw reply [flat|nested] 13+ messages in thread* Re: kernel bug at fs/ext4/resize.c:409 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-16 2:35 ` [PATCH] ext4: fix online resize with very large inode tables Theodore Ts'o 1 sibling, 1 reply; 13+ messages in thread From: Theodore Ts'o @ 2014-02-03 18:56 UTC (permalink / raw) To: linux-ext4 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? 2) Could you please send me the output of dumpe2fs of the file system? 3) Can you reproduce the problem? - Ted ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: kernel bug at fs/ext4/resize.c:409 2014-02-03 18:56 ` Theodore Ts'o @ 2014-02-06 21:08 ` Jon Bernard 2014-02-13 13:24 ` Dmitry Monakhov 0 siblings, 1 reply; 13+ messages in thread From: Jon Bernard @ 2014-02-06 21:08 UTC (permalink / raw) To: linux-ext4 [-- Attachment #1: Type: text/plain, Size: 1227 bytes --] * 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, -- Jon [-- Attachment #2: dump.txt --] [-- Type: text/plain, Size: 14952 bytes --] Filesystem volume name: cloudimg-rootfs Last mounted on: / Filesystem UUID: 942e3be7-4655-4250-8de4-7e6ffb5595e2 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 1080816 Block count: 1080688 Reserved block count: 54034 Free blocks: 338604 Free inodes: 948273 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1024 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 32752 Inode blocks per group: 2047 Flex block group size: 16 Filesystem created: Mon Feb 3 15:25:08 2014 Last mount time: Thu Feb 6 18:41:42 2014 Last write time: Thu Feb 6 18:41:41 2014 Mount count: 18 Maximum mount count: -1 Last checked: Mon Feb 3 15:25:08 2014 Check interval: 0 (<none>) Lifetime writes: 69 MB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 First orphan inode: 19343 Default directory hash: half_md4 Directory Hash Seed: 8f043eea-0268-4208-9167-34286deca46f Journal backup: inode blocks Journal features: journal_incompat_revoke Journal size: 64M Journal length: 16384 Journal sequence: 0x00000030 Journal start: 1 Group 0: (Blocks 0-32767) [ITABLE_ZEROED] Checksum 0xf064, unused inodes 0 Primary superblock at 0, Group descriptors at 1-1 Reserved GDT blocks at 2-1025 Block bitmap at 1026 (+1026), Inode bitmap at 1042 (+1042) Inode table at 1058-3104 (+1058) 0 free blocks, 0 free inodes, 5537 directories Free blocks: Free inodes: Group 1: (Blocks 32768-65535) [ITABLE_ZEROED] Checksum 0xfcf6, unused inodes 12736 Backup superblock at 32768, Group descriptors at 32769-32769 Reserved GDT blocks at 32770-33793 Block bitmap at 1027 (bg #0 + 1027), Inode bitmap at 1043 (bg #0 + 1043) Inode table at 3105-5151 (bg #0 + 3105) 0 free blocks, 12736 free inodes, 565 directories, 12736 unused inodes Free blocks: Free inodes: 52769-65504 Group 2: (Blocks 65536-98303) [ITABLE_ZEROED] Checksum 0x2191, unused inodes 30532 Block bitmap at 1028 (bg #0 + 1028), Inode bitmap at 1044 (bg #0 + 1044) Inode table at 5152-7198 (bg #0 + 5152) 0 free blocks, 30532 free inodes, 2220 directories, 30532 unused inodes Free blocks: Free inodes: 67725-98256 Group 3: (Blocks 98304-131071) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0xec2b, unused inodes 32752 Backup superblock at 98304, Group descriptors at 98305-98305 Reserved GDT blocks at 98306-99329 Block bitmap at 1029 (bg #0 + 1029), Inode bitmap at 1045 (bg #0 + 1045) Inode table at 7199-9245 (bg #0 + 7199) 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: Free inodes: 98257-131008 Group 4: (Blocks 131072-163839) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0xf126, unused inodes 32752 Block bitmap at 1030 (bg #0 + 1030), Inode bitmap at 1046 (bg #0 + 1046) Inode table at 9246-11292 (bg #0 + 9246) 132 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: 157084-157087, 157184-157311 Free inodes: 131009-163760 Group 5: (Blocks 163840-196607) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0x374c, unused inodes 32752 Backup superblock at 163840, Group descriptors at 163841-163841 Reserved GDT blocks at 163842-164865 Block bitmap at 1031 (bg #0 + 1031), Inode bitmap at 1047 (bg #0 + 1047) Inode table at 11293-13339 (bg #0 + 11293) 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: Free inodes: 163761-196512 Group 6: (Blocks 196608-229375) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0xa529, unused inodes 32752 Block bitmap at 1032 (bg #0 + 1032), Inode bitmap at 1048 (bg #0 + 1048) Inode table at 13340-15386 (bg #0 + 13340) 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: Free inodes: 196513-229264 Group 7: (Blocks 229376-262143) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0x496e, unused inodes 32752 Backup superblock at 229376, Group descriptors at 229377-229377 Reserved GDT blocks at 229378-230401 Block bitmap at 1033 (bg #0 + 1033), Inode bitmap at 1049 (bg #0 + 1049) Inode table at 15387-17433 (bg #0 + 15387) 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: Free inodes: 229265-262016 Group 8: (Blocks 262144-294911) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0xa147, unused inodes 32752 Block bitmap at 1034 (bg #0 + 1034), Inode bitmap at 1050 (bg #0 + 1050) Inode table at 17434-19480 (bg #0 + 17434) 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: Free inodes: 262017-294768 Group 9: (Blocks 294912-327679) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0x06e4, unused inodes 32752 Backup superblock at 294912, Group descriptors at 294913-294913 Reserved GDT blocks at 294914-295937 Block bitmap at 1035 (bg #0 + 1035), Inode bitmap at 1051 (bg #0 + 1051) Inode table at 19481-21527 (bg #0 + 19481) 2 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: 305491-305492 Free inodes: 294769-327520 Group 10: (Blocks 327680-360447) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0x53e4, unused inodes 32752 Block bitmap at 1036 (bg #0 + 1036), Inode bitmap at 1052 (bg #0 + 1052) Inode table at 21528-23574 (bg #0 + 21528) 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: Free inodes: 327521-360272 Group 11: (Blocks 360448-393215) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0x2764, unused inodes 32752 Block bitmap at 1037 (bg #0 + 1037), Inode bitmap at 1053 (bg #0 + 1053) Inode table at 23575-25621 (bg #0 + 23575) 52 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: 385319, 385339, 385473, 386011, 386047, 386055, 386065, 386103, 386121, 386141, 386471, 386603, 386615, 386639, 386647, 386679, 386705, 386723, 386731, 386761, 386785, 386797, 386993, 387001, 387023, 387321, 388387, 388555, 388683, 388717, 388743, 389071, 389107, 389155, 389173, 389195, 389295, 389735, 390187, 390223, 390783, 390945, 390987, 391015, 391127, 392079, 392581, 392593, 392611, 392903, 393027, 393087 Free inodes: 360273-393024 Group 12: (Blocks 393216-425983) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0xb54a, unused inodes 32752 Block bitmap at 1038 (bg #0 + 1038), Inode bitmap at 1054 (bg #0 + 1054) Inode table at 25622-27668 (bg #0 + 25622) 10189 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: 397607, 397623, 397635, 397743, 398211, 398543, 398591, 398717, 398759, 399111, 399263, 399343, 400071, 400143, 400203, 400211, 400219, 400241, 400319, 402071, 402379, 402431, 402731, 402763, 402771, 402839, 402859, 402867, 403057, 403079, 403091, 403147, 403433-403455, 415819-416255, 416271, 416273, 416277-416280, 416285-416287, 416291-416313, 416319-425983 Free inodes: 393025-425776 Group 13: (Blocks 425984-458751) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED] Checksum 0xedd5, unused inodes 32752 Block bitmap at 1039 (bg #0 + 1039), Inode bitmap at 1055 (bg #0 + 1055) Inode table at 27669-29715 (bg #0 + 27669) 32768 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: 425984-458751 Free inodes: 425777-458528 Group 14: (Blocks 458752-491519) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED] Checksum 0x3f13, unused inodes 32752 Block bitmap at 1040 (bg #0 + 1040), Inode bitmap at 1056 (bg #0 + 1056) Inode table at 29716-31762 (bg #0 + 29716) 32768 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: 458752-491519 Free inodes: 458529-491280 Group 15: (Blocks 491520-524287) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0x5e51, unused inodes 32752 Block bitmap at 1041 (bg #0 + 1041), Inode bitmap at 1057 (bg #0 + 1057) Inode table at 33794-35840 (bg #1 + 1026) 16384 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: 507904-524287 Free inodes: 491281-524032 Group 16: (Blocks 524288-557055) [ITABLE_ZEROED] Checksum 0x7c5f, unused inodes 0 Block bitmap at 524288 (+0), Inode bitmap at 524304 (+16) Inode table at 524320-526366 (+32) 0 free blocks, 0 free inodes, 2275 directories Free blocks: Free inodes: Group 17: (Blocks 557056-589823) [ITABLE_ZEROED] Checksum 0x1b57, unused inodes 0 Block bitmap at 524289 (bg #16 + 1), Inode bitmap at 524305 (bg #16 + 17) Inode table at 526367-528413 (bg #16 + 2079) 0 free blocks, 0 free inodes, 3615 directories Free blocks: Free inodes: Group 18: (Blocks 589824-622591) [ITABLE_ZEROED] Checksum 0x2677, unused inodes 22195 Block bitmap at 524290 (bg #16 + 2), Inode bitmap at 524306 (bg #16 + 18) Inode table at 528414-530460 (bg #16 + 4126) 0 free blocks, 22196 free inodes, 826 directories, 22195 unused inodes Free blocks: Free inodes: 600087, 600094-622288 Group 19: (Blocks 622592-655359) [ITABLE_ZEROED] Checksum 0x89be, unused inodes 31008 Block bitmap at 524291 (bg #16 + 3), Inode bitmap at 524307 (bg #16 + 19) Inode table at 530461-532507 (bg #16 + 6173) 0 free blocks, 31008 free inodes, 1744 directories, 31008 unused inodes Free blocks: Free inodes: 624033-655040 Group 20: (Blocks 655360-688127) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0x3b1a, unused inodes 32752 Block bitmap at 524292 (bg #16 + 4), Inode bitmap at 524308 (bg #16 + 20) Inode table at 532508-534554 (bg #16 + 8220) 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: Free inodes: 655041-687792 Group 21: (Blocks 688128-720895) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0xd75d, unused inodes 32752 Block bitmap at 524293 (bg #16 + 5), Inode bitmap at 524309 (bg #16 + 21) Inode table at 534555-536601 (bg #16 + 10267) 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: Free inodes: 687793-720544 Group 22: (Blocks 720896-753663) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0x051e, unused inodes 32752 Block bitmap at 524294 (bg #16 + 6), Inode bitmap at 524310 (bg #16 + 22) Inode table at 536602-538648 (bg #16 + 12314) 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: Free inodes: 720545-753296 Group 23: (Blocks 753664-786431) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0x1a1c, unused inodes 32752 Block bitmap at 524295 (bg #16 + 7), Inode bitmap at 524311 (bg #16 + 23) Inode table at 538649-540695 (bg #16 + 14361) 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: Free inodes: 753297-786048 Group 24: (Blocks 786432-819199) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0xb213, unused inodes 32752 Block bitmap at 524296 (bg #16 + 8), Inode bitmap at 524312 (bg #16 + 24) Inode table at 540696-542742 (bg #16 + 16408) 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: Free inodes: 786049-818800 Group 25: (Blocks 819200-851967) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0x79b0, unused inodes 32752 Backup superblock at 819200, Group descriptors at 819201-819201 Reserved GDT blocks at 819202-820225 Block bitmap at 524297 (bg #16 + 9), Inode bitmap at 524313 (bg #16 + 25) Inode table at 542743-544789 (bg #16 + 18455) 20736 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: 827392-835583, 839075-839091, 839140-839536, 839809-840191, 840193-840196, 840198, 840201, 840207, 840214-840217, 840219-840221, 840223-840231, 840237, 840239, 840246-851967 Free inodes: 818801-851552 Group 26: (Blocks 851968-884735) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED] Checksum 0x0506, unused inodes 32752 Block bitmap at 524298 (bg #16 + 10), Inode bitmap at 524314 (bg #16 + 26) Inode table at 544790-546836 (bg #16 + 20502) 32768 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: 851968-884735 Free inodes: 851553-884304 Group 27: (Blocks 884736-917503) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0x049f, unused inodes 32752 Backup superblock at 884736, Group descriptors at 884737-884737 Reserved GDT blocks at 884738-885761 Block bitmap at 524299 (bg #16 + 11), Inode bitmap at 524315 (bg #16 + 27) Inode table at 546837-548883 (bg #16 + 22549) 31742 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: 885762-917503 Free inodes: 884305-917056 Group 28: (Blocks 917504-950271) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED] Checksum 0xe183, unused inodes 32752 Block bitmap at 524300 (bg #16 + 12), Inode bitmap at 524316 (bg #16 + 28) Inode table at 548884-550930 (bg #16 + 24596) 32768 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: 917504-950271 Free inodes: 917057-949808 Group 29: (Blocks 950272-983039) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED] Checksum 0x0dc4, unused inodes 32752 Block bitmap at 524301 (bg #16 + 13), Inode bitmap at 524317 (bg #16 + 29) Inode table at 550931-552977 (bg #16 + 26643) 32768 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: 950272-983039 Free inodes: 949809-982560 Group 30: (Blocks 983040-1015807) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED] Checksum 0xdf87, unused inodes 32752 Block bitmap at 524302 (bg #16 + 14), Inode bitmap at 524318 (bg #16 + 30) Inode table at 552978-555024 (bg #16 + 28690) 32768 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: 983040-1015807 Free inodes: 982561-1015312 Group 31: (Blocks 1015808-1048575) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED] Checksum 0xc085, unused inodes 32752 Block bitmap at 524303 (bg #16 + 15), Inode bitmap at 524319 (bg #16 + 31) Inode table at 555025-557071 (bg #16 + 30737) 32768 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: 1015808-1048575 Free inodes: 1015313-1048064 Group 32: (Blocks 1048576-1080687) [INODE_UNINIT, ITABLE_ZEROED] Checksum 0x4600, unused inodes 32752 Block bitmap at 1048576 (+0), Inode bitmap at 1048592 (+16) Inode table at 1048608-1050654 (+32) 30063 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes Free blocks: 1048577-1048591, 1048593-1048607, 1050655-1080687 Free inodes: 1048065-1080816 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: kernel bug at fs/ext4/resize.c:409 2014-02-06 21:08 ` Jon Bernard @ 2014-02-13 13:24 ` Dmitry Monakhov 2014-02-13 14:53 ` Jon Bernard 0 siblings, 1 reply; 13+ messages in thread From: Dmitry Monakhov @ 2014-02-13 13:24 UTC (permalink / raw) To: Jon Bernard, linux-ext4; +Cc: Theodore Ts'o 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. > -- > Jon > Filesystem volume name: cloudimg-rootfs > Last mounted on: / > Filesystem UUID: 942e3be7-4655-4250-8de4-7e6ffb5595e2 > Filesystem magic number: 0xEF53 > Filesystem revision #: 1 (dynamic) > Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize > Filesystem flags: signed_directory_hash > Default mount options: user_xattr acl > Filesystem state: clean > Errors behavior: Continue > Filesystem OS type: Linux > Inode count: 1080816 > Block count: 1080688 > Reserved block count: 54034 > Free blocks: 338604 > Free inodes: 948273 > First block: 0 > Block size: 4096 > Fragment size: 4096 > Reserved GDT blocks: 1024 > Blocks per group: 32768 > Fragments per group: 32768 > Inodes per group: 32752 > Inode blocks per group: 2047 > Flex block group size: 16 > Filesystem created: Mon Feb 3 15:25:08 2014 > Last mount time: Thu Feb 6 18:41:42 2014 > Last write time: Thu Feb 6 18:41:41 2014 > Mount count: 18 > Maximum mount count: -1 > Last checked: Mon Feb 3 15:25:08 2014 > Check interval: 0 (<none>) > Lifetime writes: 69 MB > Reserved blocks uid: 0 (user root) > Reserved blocks gid: 0 (group root) > First inode: 11 > Inode size: 256 > Required extra isize: 28 > Desired extra isize: 28 > Journal inode: 8 > First orphan inode: 19343 > Default directory hash: half_md4 > Directory Hash Seed: 8f043eea-0268-4208-9167-34286deca46f > Journal backup: inode blocks > Journal features: journal_incompat_revoke > Journal size: 64M > Journal length: 16384 > Journal sequence: 0x00000030 > Journal start: 1 > > > Group 0: (Blocks 0-32767) [ITABLE_ZEROED] > Checksum 0xf064, unused inodes 0 > Primary superblock at 0, Group descriptors at 1-1 > Reserved GDT blocks at 2-1025 > Block bitmap at 1026 (+1026), Inode bitmap at 1042 (+1042) > Inode table at 1058-3104 (+1058) > 0 free blocks, 0 free inodes, 5537 directories > Free blocks: > Free inodes: > Group 1: (Blocks 32768-65535) [ITABLE_ZEROED] > Checksum 0xfcf6, unused inodes 12736 > Backup superblock at 32768, Group descriptors at 32769-32769 > Reserved GDT blocks at 32770-33793 > Block bitmap at 1027 (bg #0 + 1027), Inode bitmap at 1043 (bg #0 + 1043) > Inode table at 3105-5151 (bg #0 + 3105) > 0 free blocks, 12736 free inodes, 565 directories, 12736 unused inodes > Free blocks: > Free inodes: 52769-65504 > Group 2: (Blocks 65536-98303) [ITABLE_ZEROED] > Checksum 0x2191, unused inodes 30532 > Block bitmap at 1028 (bg #0 + 1028), Inode bitmap at 1044 (bg #0 + 1044) > Inode table at 5152-7198 (bg #0 + 5152) > 0 free blocks, 30532 free inodes, 2220 directories, 30532 unused inodes > Free blocks: > Free inodes: 67725-98256 > Group 3: (Blocks 98304-131071) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0xec2b, unused inodes 32752 > Backup superblock at 98304, Group descriptors at 98305-98305 > Reserved GDT blocks at 98306-99329 > Block bitmap at 1029 (bg #0 + 1029), Inode bitmap at 1045 (bg #0 + 1045) > Inode table at 7199-9245 (bg #0 + 7199) > 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: > Free inodes: 98257-131008 > Group 4: (Blocks 131072-163839) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0xf126, unused inodes 32752 > Block bitmap at 1030 (bg #0 + 1030), Inode bitmap at 1046 (bg #0 + 1046) > Inode table at 9246-11292 (bg #0 + 9246) > 132 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: 157084-157087, 157184-157311 > Free inodes: 131009-163760 > Group 5: (Blocks 163840-196607) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0x374c, unused inodes 32752 > Backup superblock at 163840, Group descriptors at 163841-163841 > Reserved GDT blocks at 163842-164865 > Block bitmap at 1031 (bg #0 + 1031), Inode bitmap at 1047 (bg #0 + 1047) > Inode table at 11293-13339 (bg #0 + 11293) > 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: > Free inodes: 163761-196512 > Group 6: (Blocks 196608-229375) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0xa529, unused inodes 32752 > Block bitmap at 1032 (bg #0 + 1032), Inode bitmap at 1048 (bg #0 + 1048) > Inode table at 13340-15386 (bg #0 + 13340) > 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: > Free inodes: 196513-229264 > Group 7: (Blocks 229376-262143) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0x496e, unused inodes 32752 > Backup superblock at 229376, Group descriptors at 229377-229377 > Reserved GDT blocks at 229378-230401 > Block bitmap at 1033 (bg #0 + 1033), Inode bitmap at 1049 (bg #0 + 1049) > Inode table at 15387-17433 (bg #0 + 15387) > 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: > Free inodes: 229265-262016 > Group 8: (Blocks 262144-294911) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0xa147, unused inodes 32752 > Block bitmap at 1034 (bg #0 + 1034), Inode bitmap at 1050 (bg #0 + 1050) > Inode table at 17434-19480 (bg #0 + 17434) > 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: > Free inodes: 262017-294768 > Group 9: (Blocks 294912-327679) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0x06e4, unused inodes 32752 > Backup superblock at 294912, Group descriptors at 294913-294913 > Reserved GDT blocks at 294914-295937 > Block bitmap at 1035 (bg #0 + 1035), Inode bitmap at 1051 (bg #0 + 1051) > Inode table at 19481-21527 (bg #0 + 19481) > 2 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: 305491-305492 > Free inodes: 294769-327520 > Group 10: (Blocks 327680-360447) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0x53e4, unused inodes 32752 > Block bitmap at 1036 (bg #0 + 1036), Inode bitmap at 1052 (bg #0 + 1052) > Inode table at 21528-23574 (bg #0 + 21528) > 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: > Free inodes: 327521-360272 > Group 11: (Blocks 360448-393215) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0x2764, unused inodes 32752 > Block bitmap at 1037 (bg #0 + 1037), Inode bitmap at 1053 (bg #0 + 1053) > Inode table at 23575-25621 (bg #0 + 23575) > 52 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: 385319, 385339, 385473, 386011, 386047, 386055, 386065, 386103, 386121, 386141, 386471, 386603, 386615, 386639, 386647, 386679, 386705, 386723, 386731, 386761, 386785, 386797, 386993, 387001, 387023, 387321, 388387, 388555, 388683, 388717, 388743, 389071, 389107, 389155, 389173, 389195, 389295, 389735, 390187, 390223, 390783, 390945, 390987, 391015, 391127, 392079, 392581, 392593, 392611, 392903, 393027, 393087 > Free inodes: 360273-393024 > Group 12: (Blocks 393216-425983) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0xb54a, unused inodes 32752 > Block bitmap at 1038 (bg #0 + 1038), Inode bitmap at 1054 (bg #0 + 1054) > Inode table at 25622-27668 (bg #0 + 25622) > 10189 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: 397607, 397623, 397635, 397743, 398211, 398543, 398591, 398717, 398759, 399111, 399263, 399343, 400071, 400143, 400203, 400211, 400219, 400241, 400319, 402071, 402379, 402431, 402731, 402763, 402771, 402839, 402859, 402867, 403057, 403079, 403091, 403147, 403433-403455, 415819-416255, 416271, 416273, 416277-416280, 416285-416287, 416291-416313, 416319-425983 > Free inodes: 393025-425776 > Group 13: (Blocks 425984-458751) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED] > Checksum 0xedd5, unused inodes 32752 > Block bitmap at 1039 (bg #0 + 1039), Inode bitmap at 1055 (bg #0 + 1055) > Inode table at 27669-29715 (bg #0 + 27669) > 32768 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: 425984-458751 > Free inodes: 425777-458528 > Group 14: (Blocks 458752-491519) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED] > Checksum 0x3f13, unused inodes 32752 > Block bitmap at 1040 (bg #0 + 1040), Inode bitmap at 1056 (bg #0 + 1056) > Inode table at 29716-31762 (bg #0 + 29716) > 32768 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: 458752-491519 > Free inodes: 458529-491280 > Group 15: (Blocks 491520-524287) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0x5e51, unused inodes 32752 > Block bitmap at 1041 (bg #0 + 1041), Inode bitmap at 1057 (bg #0 + 1057) > Inode table at 33794-35840 (bg #1 + 1026) > 16384 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: 507904-524287 > Free inodes: 491281-524032 > Group 16: (Blocks 524288-557055) [ITABLE_ZEROED] > Checksum 0x7c5f, unused inodes 0 > Block bitmap at 524288 (+0), Inode bitmap at 524304 (+16) > Inode table at 524320-526366 (+32) > 0 free blocks, 0 free inodes, 2275 directories > Free blocks: > Free inodes: > Group 17: (Blocks 557056-589823) [ITABLE_ZEROED] > Checksum 0x1b57, unused inodes 0 > Block bitmap at 524289 (bg #16 + 1), Inode bitmap at 524305 (bg #16 + 17) > Inode table at 526367-528413 (bg #16 + 2079) > 0 free blocks, 0 free inodes, 3615 directories > Free blocks: > Free inodes: > Group 18: (Blocks 589824-622591) [ITABLE_ZEROED] > Checksum 0x2677, unused inodes 22195 > Block bitmap at 524290 (bg #16 + 2), Inode bitmap at 524306 (bg #16 + 18) > Inode table at 528414-530460 (bg #16 + 4126) > 0 free blocks, 22196 free inodes, 826 directories, 22195 unused inodes > Free blocks: > Free inodes: 600087, 600094-622288 > Group 19: (Blocks 622592-655359) [ITABLE_ZEROED] > Checksum 0x89be, unused inodes 31008 > Block bitmap at 524291 (bg #16 + 3), Inode bitmap at 524307 (bg #16 + 19) > Inode table at 530461-532507 (bg #16 + 6173) > 0 free blocks, 31008 free inodes, 1744 directories, 31008 unused inodes > Free blocks: > Free inodes: 624033-655040 > Group 20: (Blocks 655360-688127) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0x3b1a, unused inodes 32752 > Block bitmap at 524292 (bg #16 + 4), Inode bitmap at 524308 (bg #16 + 20) > Inode table at 532508-534554 (bg #16 + 8220) > 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: > Free inodes: 655041-687792 > Group 21: (Blocks 688128-720895) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0xd75d, unused inodes 32752 > Block bitmap at 524293 (bg #16 + 5), Inode bitmap at 524309 (bg #16 + 21) > Inode table at 534555-536601 (bg #16 + 10267) > 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: > Free inodes: 687793-720544 > Group 22: (Blocks 720896-753663) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0x051e, unused inodes 32752 > Block bitmap at 524294 (bg #16 + 6), Inode bitmap at 524310 (bg #16 + 22) > Inode table at 536602-538648 (bg #16 + 12314) > 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: > Free inodes: 720545-753296 > Group 23: (Blocks 753664-786431) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0x1a1c, unused inodes 32752 > Block bitmap at 524295 (bg #16 + 7), Inode bitmap at 524311 (bg #16 + 23) > Inode table at 538649-540695 (bg #16 + 14361) > 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: > Free inodes: 753297-786048 > Group 24: (Blocks 786432-819199) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0xb213, unused inodes 32752 > Block bitmap at 524296 (bg #16 + 8), Inode bitmap at 524312 (bg #16 + 24) > Inode table at 540696-542742 (bg #16 + 16408) > 0 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: > Free inodes: 786049-818800 > Group 25: (Blocks 819200-851967) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0x79b0, unused inodes 32752 > Backup superblock at 819200, Group descriptors at 819201-819201 > Reserved GDT blocks at 819202-820225 > Block bitmap at 524297 (bg #16 + 9), Inode bitmap at 524313 (bg #16 + 25) > Inode table at 542743-544789 (bg #16 + 18455) > 20736 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: 827392-835583, 839075-839091, 839140-839536, 839809-840191, 840193-840196, 840198, 840201, 840207, 840214-840217, 840219-840221, 840223-840231, 840237, 840239, 840246-851967 > Free inodes: 818801-851552 > Group 26: (Blocks 851968-884735) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED] > Checksum 0x0506, unused inodes 32752 > Block bitmap at 524298 (bg #16 + 10), Inode bitmap at 524314 (bg #16 + 26) > Inode table at 544790-546836 (bg #16 + 20502) > 32768 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: 851968-884735 > Free inodes: 851553-884304 > Group 27: (Blocks 884736-917503) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0x049f, unused inodes 32752 > Backup superblock at 884736, Group descriptors at 884737-884737 > Reserved GDT blocks at 884738-885761 > Block bitmap at 524299 (bg #16 + 11), Inode bitmap at 524315 (bg #16 + 27) > Inode table at 546837-548883 (bg #16 + 22549) > 31742 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: 885762-917503 > Free inodes: 884305-917056 > Group 28: (Blocks 917504-950271) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED] > Checksum 0xe183, unused inodes 32752 > Block bitmap at 524300 (bg #16 + 12), Inode bitmap at 524316 (bg #16 + 28) > Inode table at 548884-550930 (bg #16 + 24596) > 32768 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: 917504-950271 > Free inodes: 917057-949808 > Group 29: (Blocks 950272-983039) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED] > Checksum 0x0dc4, unused inodes 32752 > Block bitmap at 524301 (bg #16 + 13), Inode bitmap at 524317 (bg #16 + 29) > Inode table at 550931-552977 (bg #16 + 26643) > 32768 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: 950272-983039 > Free inodes: 949809-982560 > Group 30: (Blocks 983040-1015807) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED] > Checksum 0xdf87, unused inodes 32752 > Block bitmap at 524302 (bg #16 + 14), Inode bitmap at 524318 (bg #16 + 30) > Inode table at 552978-555024 (bg #16 + 28690) > 32768 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: 983040-1015807 > Free inodes: 982561-1015312 > Group 31: (Blocks 1015808-1048575) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED] > Checksum 0xc085, unused inodes 32752 > Block bitmap at 524303 (bg #16 + 15), Inode bitmap at 524319 (bg #16 + 31) > Inode table at 555025-557071 (bg #16 + 30737) > 32768 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: 1015808-1048575 > Free inodes: 1015313-1048064 > Group 32: (Blocks 1048576-1080687) [INODE_UNINIT, ITABLE_ZEROED] > Checksum 0x4600, unused inodes 32752 > Block bitmap at 1048576 (+0), Inode bitmap at 1048592 (+16) > Inode table at 1048608-1050654 (+32) > 30063 free blocks, 32752 free inodes, 0 directories, 32752 unused inodes > Free blocks: 1048577-1048591, 1048593-1048607, 1050655-1080687 > Free inodes: 1048065-1080816 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: kernel bug at fs/ext4/resize.c:409 2014-02-13 13:24 ` Dmitry Monakhov @ 2014-02-13 14:53 ` Jon Bernard 2014-02-13 21:18 ` Theodore Ts'o 0 siblings, 1 reply; 13+ messages in thread From: Jon Bernard @ 2014-02-13 14:53 UTC (permalink / raw) To: Dmitry Monakhov; +Cc: linux-ext4, Theodore Ts'o * 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 ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: kernel bug at fs/ext4/resize.c:409 2014-02-13 14:53 ` Jon Bernard @ 2014-02-13 21:18 ` Theodore Ts'o 2014-02-13 21:27 ` Theodore Ts'o ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Theodore Ts'o @ 2014-02-13 21:18 UTC (permalink / raw) To: Dmitry Monakhov, linux-ext4 On Thu, Feb 13, 2014 at 09:53:23AM -0500, Jon Bernard wrote: > The image should be available here: > > http://c5a6e06e970802d5126f-8c6b900f6923cc24b844c506080778ec.r72.cf1.rackcdn.com/fedora_resize_fails.qcow2 Thanks for the image. I've been able to reproduce the problem, and it's caused by the fact that the inode table is so large that it's overflowing into a subsequent block group, and the resize code isn't handling this. Fixing this may be a bit tricky, since the flex_bg online resize code is a big ugly at the moment, and needs some clean up so this can be fixed properly. Until that can be done --- one question: was there a deliberate reason why the file system was created with parameters which allocate 32,752 inodes per block group? That means that a bit over 8 megabytes of inode table are being reserved for every 128 megabyte (32768 4k blocks) block group, and that you have more inodes reserved than could be used if the average file size is 4k or less. In fact, the only way you could run out of inodes is if you had huge numbers of devices, sockets, small symlinks, or zero-length files in your file system. This seems to be a bit of a waste of space, in all liklihood. Don't get me wrong; we should be able to handle this case correctly, and not trigger a BUG_ON, but this is why most people aren't seeing this particular fault --- it requires a far greater number of inodes than mke2fs would ever create by default, or that most system administrators would try to deliberately specify, when creating the file system. I'll look and see what's the best way to fix up fs/ext4/resize.c in the kernel. Regards, - Ted ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: kernel bug at fs/ext4/resize.c:409 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 2 siblings, 0 replies; 13+ messages in thread From: Theodore Ts'o @ 2014-02-13 21:27 UTC (permalink / raw) To: Jon Bernard, Dmitry Monakhov, linux-ext4 +Jon Bernard (who somehow got dropped from the e-mail thread when I tried to reply) On Thu, Feb 13, 2014 at 04:18:31PM -0500, Theodore Ts'o wrote: > On Thu, Feb 13, 2014 at 09:53:23AM -0500, Jon Bernard wrote: > > The image should be available here: > > > > http://c5a6e06e970802d5126f-8c6b900f6923cc24b844c506080778ec.r72.cf1.rackcdn.com/fedora_resize_fails.qcow2 > > Thanks for the image. I've been able to reproduce the problem, and > it's caused by the fact that the inode table is so large that it's > overflowing into a subsequent block group, and the resize code isn't > handling this. Fixing this may be a bit tricky, since the flex_bg > online resize code is a big ugly at the moment, and needs some clean > up so this can be fixed properly. > > Until that can be done --- one question: was there a deliberate reason > why the file system was created with parameters which allocate 32,752 > inodes per block group? That means that a bit over 8 megabytes of > inode table are being reserved for every 128 megabyte (32768 4k > blocks) block group, and that you have more inodes reserved than could > be used if the average file size is 4k or less. In fact, the only way > you could run out of inodes is if you had huge numbers of devices, > sockets, small symlinks, or zero-length files in your file system. > This seems to be a bit of a waste of space, in all liklihood. > > Don't get me wrong; we should be able to handle this case correctly, > and not trigger a BUG_ON, but this is why most people aren't seeing > this particular fault --- it requires a far greater number of inodes > than mke2fs would ever create by default, or that most system > administrators would try to deliberately specify, when creating the > file system. > > I'll look and see what's the best way to fix up fs/ext4/resize.c in > the kernel. > > Regards, > > - Ted ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: kernel bug at fs/ext4/resize.c:409 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 2 siblings, 0 replies; 13+ messages in thread From: Andreas Dilger @ 2014-02-14 3:13 UTC (permalink / raw) To: Theodore Ts'o; +Cc: Dmitry Monakhov, linux-ext4 On Feb 13, 2014, at 14:18, Theodore Ts'o <tytso@mit.edu> wrote: > one question: was there a deliberate reason > why the file system was created with parameters which allocate 32,752 > inodes per block group? That means that a bit over 8 megabytes of > inode table are being reserved for every 128 megabyte (32768 4k > blocks) block group, and that you have more inodes reserved than could > be used if the average file size is 4k or less. This is fairly normal for Lustre metadata targets, where the inodes typically do not have any data blocks. We typically format the MDT filesystem with an average of 2KB per inode. > In fact, the only way > you could run out of inodes is if you had huge numbers of devices, > sockets, small symlinks, or zero-length files in your file system. > This seems to be a bit of a waste of space, in all liklihood. > > Don't get me wrong; we should be able to handle this case correctly, > and not trigger a BUG_ON, but this is why most people aren't seeing > this particular fault --- it requires a far greater number of inodes > than mke2fs would ever create by default, or that most system > administrators would try to deliberately specify, when creating the > file system. That said, Lustre also doesn't allow online resize yet (no way to pass the ioctl() from userspace to the underlying ext4 filesystem), so we haven't hit this yet. Cheers, Andreas ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: kernel bug at fs/ext4/resize.c:409 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 2 siblings, 1 reply; 13+ messages in thread From: Jon Bernard @ 2014-02-14 20:19 UTC (permalink / raw) To: Theodore Ts'o; +Cc: Dmitry Monakhov, linux-ext4 * Theodore Ts'o <tytso@mit.edu> wrote: > On Thu, Feb 13, 2014 at 09:53:23AM -0500, Jon Bernard wrote: > > The image should be available here: > > > > http://c5a6e06e970802d5126f-8c6b900f6923cc24b844c506080778ec.r72.cf1.rackcdn.com/fedora_resize_fails.qcow2 > > Thanks for the image. I've been able to reproduce the problem, and > it's caused by the fact that the inode table is so large that it's > overflowing into a subsequent block group, and the resize code isn't > handling this. Fixing this may be a bit tricky, since the flex_bg > online resize code is a big ugly at the moment, and needs some clean > up so this can be fixed properly. > > Until that can be done --- one question: was there a deliberate reason > why the file system was created with parameters which allocate 32,752 > inodes per block group? That means that a bit over 8 megabytes of > inode table are being reserved for every 128 megabyte (32768 4k > blocks) block group, and that you have more inodes reserved than could > be used if the average file size is 4k or less. In fact, the only way > you could run out of inodes is if you had huge numbers of devices, > sockets, small symlinks, or zero-length files in your file system. > This seems to be a bit of a waste of space, in all liklihood. Ahh, I see. Here's where this comes from: the particular usecase is provisioning of new cloud instances whose root volume is of unknown size. The filesystem and its contents are created and bundled before-hand into the smallest filesystem possible. The instance is PXE booted for provisioning and the root filesystem is then copied onto the disk - and then resized to take advantage of the total amount of space. In order to support very large partitions, the filesystem is created with an abnormally large inode table so that large resizes would be possible. I traced it to this commit as best I can tell: https://github.com/openstack/diskimage-builder/commit/fb246a02eb2ed330d3cc37f5795b3ed026aabe07 I assumed that additional inodes would be allocated along with block groups during an online resize, but that commit contradicts my current understanding. I suggested that the filesystem be created during the time of provisioning to allow a more optimal on-disk layout, and I believe this is being considered now. > Don't get me wrong; we should be able to handle this case correctly, > and not trigger a BUG_ON, but this is why most people aren't seeing > this particular fault --- it requires a far greater number of inodes > than mke2fs would ever create by default, or that most system > administrators would try to deliberately specify, when creating the > file system. Thank you for taking the time to look into this, it is very much appreciated. > I'll look and see what's the best way to fix up fs/ext4/resize.c in > the kernel. If it turns out to be not terribly complicated and there is not an immediate time constraint, I would love to try to help with this or at least test patches. Cheers, -- Jon ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: kernel bug at fs/ext4/resize.c:409 2014-02-14 20:19 ` Jon Bernard @ 2014-02-14 23:46 ` Theodore Ts'o 2014-02-15 3:16 ` Darrick J. Wong 0 siblings, 1 reply; 13+ messages in thread From: Theodore Ts'o @ 2014-02-14 23:46 UTC (permalink / raw) To: Jon Bernard; +Cc: Dmitry Monakhov, linux-ext4 On Fri, Feb 14, 2014 at 03:19:05PM -0500, Jon Bernard wrote: > Ahh, I see. Here's where this comes from: the particular usecase is > provisioning of new cloud instances whose root volume is of unknown > size. The filesystem and its contents are created and bundled > before-hand into the smallest filesystem possible. The instance is PXE > booted for provisioning and the root filesystem is then copied onto the > disk - and then resized to take advantage of the total amount of space. > > In order to support very large partitions, the filesystem is created > with an abnormally large inode table so that large resizes would be > possible. I traced it to this commit as best I can tell: > > https://github.com/openstack/diskimage-builder/commit/fb246a02eb2ed330d3cc37f5795b3ed026aabe07 > > I assumed that additional inodes would be allocated along with block > groups during an online resize, but that commit contradicts my current > understanding. Additional inodes *are* allocated as the file system is grown. However thought otherwise was wrong. What happens is that there is a fixed number of inodes per block group. When the file system is resized, either by growing or shrinking file system, as block groups are added or removed from the file system, the number of inodes is also added or removed. > I suggested that the filesystem be created during the time of > provisioning to allow a more optimal on-disk layout, and I believe this > is being considered now. What causes the most damage in terms of a non-optimal data block layout, installing the file system on a large file system, and then shrinking the file system to its minimum size use resize2fs -M. There is so some non-optimality that occurs as the file system gets filled beyond about 90% full, but that it's not nearly so bad as shrinking the file system --- which you should avoid at all costs. >From a performance point of view, the only time you should try to do an off-line resize2fs shrink is if you are shrinking the file system by a handful of blocks as part of converting a file system in place to use LVM or LUKS encryption, and you need to make room for some metadata blocks at the end of the partition. The other thing thing to note is that if you are using a format such as qcow2, or something like the device-mapper's thin-provisining (thinkp) scheme, or if you are willing to deal with sparse files, one approach is to not resize the file system at all. You could just use a tool like zerofree[1] to zero out all of the unused blocks in the file system, and then use "/bin/cp --sparse==always" to cause all zero blocks to be treated as sparse blocks on the destination file. [1] http://git.kernel.org/cgit/fs/ext2/xfstests-bld.git/tree/kvm-xfstests/util/zerofree.c This is part of how I maintain my root filesystem that I use in a VM for testing ext4 changes upstream. After I update to the latest Debian unstable package updates, install the latest updates from the xfstests and e2fsprogs git repositories, I then run the following script which uses the zerofree.c program to compress the qcow2 root file system image that I use with kvm: http://git.kernel.org/cgit/fs/ext2/xfstests-bld.git/tree/kvm-xfstests/compress-rootfs Also, starting with e2fsprogs 1.42.10, there's another way you can efficiently deploy a large file system image by only copying the blocks which are in use, by using a command like this: e2image -rap src_fs dest_fs (See also the -c flag as described in e2image's man page if you want to use this technique to do incremental image-based backups onto a flash-based backup medium; I was using this for a while to keep two laptop SSD's root filesystem in sync with one another.) So there are lots of ways that you can do what you need, all without playing games with resize2fs. Perhaps some of them would actually be better for your use case. > If it turns out to be not terribly complicated and there is not an > immediate time constraint, I would love to try to help with this or at > least test patches. I will hopefully have a bug fix in the next week or two. Cheers, - Ted ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: kernel bug at fs/ext4/resize.c:409 2014-02-14 23:46 ` Theodore Ts'o @ 2014-02-15 3:16 ` Darrick J. Wong 2014-02-15 15:34 ` Theodore Ts'o 0 siblings, 1 reply; 13+ messages in thread From: Darrick J. Wong @ 2014-02-15 3:16 UTC (permalink / raw) To: Theodore Ts'o; +Cc: Jon Bernard, Dmitry Monakhov, linux-ext4 Per Ted's request, I've started editing a document on the ext4 wiki: https://ext4.wiki.kernel.org/index.php/Ext4_VM_Images [comments below too] On Fri, Feb 14, 2014 at 06:46:31PM -0500, Theodore Ts'o wrote: > On Fri, Feb 14, 2014 at 03:19:05PM -0500, Jon Bernard wrote: > > Ahh, I see. Here's where this comes from: the particular usecase is > > provisioning of new cloud instances whose root volume is of unknown > > size. The filesystem and its contents are created and bundled > > before-hand into the smallest filesystem possible. The instance is PXE > > booted for provisioning and the root filesystem is then copied onto the > > disk - and then resized to take advantage of the total amount of space. > > > > In order to support very large partitions, the filesystem is created > > with an abnormally large inode table so that large resizes would be > > possible. I traced it to this commit as best I can tell: > > > > https://github.com/openstack/diskimage-builder/commit/fb246a02eb2ed330d3cc37f5795b3ed026aabe07 > > > > I assumed that additional inodes would be allocated along with block > > groups during an online resize, but that commit contradicts my current > > understanding. > > Additional inodes *are* allocated as the file system is grown. > However thought otherwise was wrong. What happens is that there is a > fixed number of inodes per block group. When the file system is > resized, either by growing or shrinking file system, as block groups > are added or removed from the file system, the number of inodes > is also added or removed. > > > I suggested that the filesystem be created during the time of > > provisioning to allow a more optimal on-disk layout, and I believe this > > is being considered now. > > What causes the most damage in terms of a non-optimal data block > layout, installing the file system on a large file system, and then > shrinking the file system to its minimum size use resize2fs -M. There > is so some non-optimality that occurs as the file system gets filled > beyond about 90% full, but that it's not nearly so bad as shrinking > the file system --- which you should avoid at all costs. > > From a performance point of view, the only time you should try to do > an off-line resize2fs shrink is if you are shrinking the file system > by a handful of blocks as part of converting a file system in place to > use LVM or LUKS encryption, and you need to make room for some > metadata blocks at the end of the partition. > > The other thing thing to note is that if you are using a format such > as qcow2, or something like the device-mapper's thin-provisining > (thinkp) scheme, or if you are willing to deal with sparse files, one > approach is to not resize the file system at all. You could just use > a tool like zerofree[1] to zero out all of the unused blocks in the > file system, and then use "/bin/cp --sparse==always" to cause all zero > blocks to be treated as sparse blocks on the destination file. > > [1] http://git.kernel.org/cgit/fs/ext2/xfstests-bld.git/tree/kvm-xfstests/util/zerofree.c I have a zerofree variant that knows how to punch/discard blocks that I'll throw into contrib/ the next time I send out one of my megapatch sets. > This is part of how I maintain my root filesystem that I use in a VM > for testing ext4 changes upstream. After I update to the latest > Debian unstable package updates, install the latest updates from the > xfstests and e2fsprogs git repositories, I then run the following > script which uses the zerofree.c program to compress the qcow2 root > file system image that I use with kvm: > > http://git.kernel.org/cgit/fs/ext2/xfstests-bld.git/tree/kvm-xfstests/compress-rootfs > > > Also, starting with e2fsprogs 1.42.10, there's another way you can These three options (-rap) are available in 1.42.9. Is there a particular reason not to use it before 1.42.10? > efficiently deploy a large file system image by only copying the > blocks which are in use, by using a command like this: > > e2image -rap src_fs dest_fs > > (See also the -c flag as described in e2image's man page if you want > to use this technique to do incremental image-based backups onto a > flash-based backup medium; I was using this for a while to keep two > laptop SSD's root filesystem in sync with one another.) > > So there are lots of ways that you can do what you need, all without > playing games with resize2fs. Perhaps some of them would actually be > better for your use case. Calvin Watson noted on Ted's G+ repost that one can use fstrim in newer versions of QEMU (1.5+?) to punch out unused blocks if the virtual disk is emulated via virtio-scsi. --D > > > > If it turns out to be not terribly complicated and there is not an > > immediate time constraint, I would love to try to help with this or at > > least test patches. > > I will hopefully have a bug fix in the next week or two. > > Cheers, > > - Ted > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: kernel bug at fs/ext4/resize.c:409 2014-02-15 3:16 ` Darrick J. Wong @ 2014-02-15 15:34 ` Theodore Ts'o 0 siblings, 0 replies; 13+ messages in thread From: Theodore Ts'o @ 2014-02-15 15:34 UTC (permalink / raw) To: Darrick J. Wong; +Cc: Jon Bernard, Dmitry Monakhov, linux-ext4 On Fri, Feb 14, 2014 at 07:16:24PM -0800, Darrick J. Wong wrote: > > > > Also, starting with e2fsprogs 1.42.10, there's another way you can > > These three options (-rap) are available in 1.42.9. Is there a particular > reason not to use it before 1.42.10? That was a typo, sorry. I had intended to write 1.42.9, since 1.42.10 isn't out yet. Checking to be sure, there are some coverity fixes for e2image that are pending that aren't in 1.42.9 relating to e2image, but none of them are super serious. The worst of them is a printf type mismatch when printing the final progress report. This doesn't seem to cause a problem on x86_64 architectures, but since it is a 64 vs 32 bit mismatch, it could cause problems on 32 bit architectures. I haven't checked to see whether it causes a cosmetic failure, or a seg fault on an i386 system, but if it is a seg fault, e2image would have completed the file system copy at that point anyway. In any case, this will be fixed in the next release, and the fix is in the Debian package already. Thanks for adding this information to the ext4 wiki! - Ted ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH] ext4: fix online resize with very large inode tables 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-16 2:35 ` Theodore Ts'o 1 sibling, 0 replies; 13+ messages in thread From: Theodore Ts'o @ 2014-02-16 2:35 UTC (permalink / raw) To: Ext4 Developers List; +Cc: Jon Bernard, Theodore Ts'o, stable If a file system has a large number of inodes per block group, all of the metadata blocks in a flex_bg may be larger than what can fit in a single block group. Unfortunately, ext4_alloc_group_tables() in resize.c was never tested to see if it would handle this case correctly, and there were a large number of bugs which caused the following sequence to result in a BUG_ON: kernel bug at fs/ext4/resize.c:409! ... call trace: [<ffffffff81256768>] ext4_flex_group_add+0x1448/0x1830 [<ffffffff81257de2>] ext4_resize_fs+0x7b2/0xe80 [<ffffffff8123ac50>] ext4_ioctl+0xbf0/0xf00 [<ffffffff811c111d>] do_vfs_ioctl+0x2dd/0x4b0 [<ffffffff811b9df2>] ? final_putname+0x22/0x50 [<ffffffff811c1371>] sys_ioctl+0x81/0xa0 [<ffffffff81676aa9>] system_call_fastpath+0x16/0x1b code: c8 4c 89 df e8 41 96 f8 ff 44 89 e8 49 01 c4 44 29 6d d4 0 rip [<ffffffff81254fa1>] set_flexbg_block_bitmap+0x171/0x180 This can be reproduced with the following command sequence: mke2fs -t ext4 -i 4096 /dev/vdd 1G mount -t ext4 /dev/vdd /vdd resize2fs /dev/vdd 8G To fix this, we need to make sure the right thing happens when a block group's inode table straddles two block groups, which means the following bugs had to be fixed: 1) Not clearing the BLOCK_UNINIT flag in the second block group in ext4_alloc_group_tables --- the was proximate cause of the BUG_ON. 2) Incorrectly determining how many block groups contained contiguous free blocks in ext4_alloc_group_tables(). 3) Incorrectly setting the start of the next block range to be marked in use after a discontinuity in setup_new_flex_group_blocks(). Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: stable@vger.kernel.org --- fs/ext4/resize.c | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index c5adbb3..69a6261 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -243,6 +243,7 @@ static int ext4_alloc_group_tables(struct super_block *sb, ext4_group_t group; ext4_group_t last_group; unsigned overhead; + __u16 uninit_mask = (flexbg_size > 1) ? ~EXT4_BG_BLOCK_UNINIT : ~0; BUG_ON(flex_gd->count == 0 || group_data == NULL); @@ -266,7 +267,7 @@ next_group: src_group++; for (; src_group <= last_group; src_group++) { overhead = ext4_group_overhead_blocks(sb, src_group); - if (overhead != 0) + if (overhead == 0) last_blk += group_data[src_group - group].blocks_count; else break; @@ -280,8 +281,7 @@ next_group: group = ext4_get_group_number(sb, start_blk - 1); group -= group_data[0].group; group_data[group].free_blocks_count--; - if (flexbg_size > 1) - flex_gd->bg_flags[group] &= ~EXT4_BG_BLOCK_UNINIT; + flex_gd->bg_flags[group] &= uninit_mask; } /* Allocate inode bitmaps */ @@ -292,22 +292,30 @@ next_group: group = ext4_get_group_number(sb, start_blk - 1); group -= group_data[0].group; group_data[group].free_blocks_count--; - if (flexbg_size > 1) - flex_gd->bg_flags[group] &= ~EXT4_BG_BLOCK_UNINIT; + flex_gd->bg_flags[group] &= uninit_mask; } /* Allocate inode tables */ for (; it_index < flex_gd->count; it_index++) { - if (start_blk + EXT4_SB(sb)->s_itb_per_group > last_blk) + unsigned int itb = EXT4_SB(sb)->s_itb_per_group; + ext4_fsblk_t next_group_start; + + if (start_blk + itb > last_blk) goto next_group; group_data[it_index].inode_table = start_blk; - group = ext4_get_group_number(sb, start_blk - 1); + group = ext4_get_group_number(sb, start_blk); + next_group_start = ext4_group_first_block_no(sb, group + 1); group -= group_data[0].group; - group_data[group].free_blocks_count -= - EXT4_SB(sb)->s_itb_per_group; - if (flexbg_size > 1) - flex_gd->bg_flags[group] &= ~EXT4_BG_BLOCK_UNINIT; + if (start_blk + itb > next_group_start) { + flex_gd->bg_flags[group + 1] &= uninit_mask; + overhead = start_blk + itb - next_group_start; + group_data[group + 1].free_blocks_count -= overhead; + itb -= overhead; + } + + group_data[group].free_blocks_count -= itb; + flex_gd->bg_flags[group] &= uninit_mask; start_blk += EXT4_SB(sb)->s_itb_per_group; } @@ -620,7 +628,7 @@ handle_ib: if (err) goto out; count = group_table_count[j]; - start = group_data[i].block_bitmap; + start = (&group_data[i].block_bitmap)[j]; block = start; } -- 1.8.5.rc3.362.gdf10213 ^ permalink raw reply related [flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-02-16 2:35 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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).