Description of problem: After resizing a partition on a LVM logical volume, kernel issues some warnings and finally oops. Version-Release number of selected component (if applicable): kernel-2.6.17-1.2139_FC5 e2fsprogs-1.38-12 How reproducible: Don't know. Steps to Reproduce (these are the actual steps that were taken): 1. Extend a lv with lvm: lvextend -l +1 /dev/vg0/disk 2. Use ext2online: ext2online /dev/vg0/disk 3. Watch the kernel log for errors Actual results: Kernel log: You end up with a lot of these: EXT3-fs warning (device dm-1): dx_probe: Unimplemented inode hash depth: 0x0070 EXT3-fs warning (device dm-1): dx_probe: Unrecognised inode hash code 87 init_special_inode: bogus i_mode (71563) Culminating in: EXT3-fs error (device dm-1): ext3_find_entry: bad entry in directory #24682062: directory entry across blocks - offset=0, inode=2099261488, rec_len=32032, name_len=44 Aborting journal on device dm-1. ext3_abort called. And a little bit later: Assertion failure in dx_probe() at fs/ext3/namei.c:383: "dx_get_limit(entries) == dx_root_limit(dir, root->info.info_length)" ----------- [cut here ] --------- [please bite here ] --------- Kernel BUG at fs/ext3/namei.c:383 invalid opcode: 0000 [1] SMP last sysfs file: /block/dm-2/stat CPU 1 Modules linked in: visor usbserial radeon drm nfsd exportfs lockd nfs_acl w83627hf eeprom lm85 hwmon_vid hwmon i2c_isa sunrpc video button battery acpi_memhotplug ac ipv6 lp parport_pc parport snd_usb_audio snd_usb_lib snd_rawmidi snd_hwdep usb_storage pwc videodev ohci1394 floppy ieee1394 ehci_hcd ohci_hcd sr_mod snd_intel8x0 sg snd_ac97_codec snd_ac97_bus snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm hw_random snd_timer snd soundcore snd_page_alloc i2c_amd756 tg3 i2c_amd8111 i2c_core dm_snapshot dm_zero dm_mirror dm_mod ext3 jbd aic7xxx scsi_transport_spi sd_mod scsi_mod Pid: 19067, comm: updatedb Not tainted 2.6.17-1.2139_FC5 #1 RIP: 0010:[<ffffffff880a213c>] <ffffffff880a213c>{:ext3:dx_probe+331} RSP: 0018:ffff810041031a58 EFLAGS: 00010282 RAX: 0000000000000081 RBX: ffff81001d9df018 RCX: ffffffff80548a98 RDX: 0000000000000000 RSI: 0000000000000292 RDI: ffffffff80548a80 RBP: ffff81006e3b76d0 R08: ffffffff80548a98 R09: ffff8100410317a8 R10: 00000000ffffffff R11: 0000000000000000 R12: 0000000000000000 R13: ffff81006d15fcd0 R14: ffff810016d1a7d8 R15: ffff810041031bd4 FS: 00002aaaaaad5230(0000) GS:ffff81004007f640(0000) knlGS:00000000f7e566d0 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00002aaaae69d000 CR3: 0000000056cca000 CR4: 00000000000006e0 Process updatedb (pid: 19067, threadinfo ffff810041030000, task ffff810040231860) Stack: ffff810041031b78 ffff810000000002 5defabdc00000000 ffff81006e3b76d0 ffff810016d1a7d8 ffff81006e3b76d0 ffff810016d1a8b0 ffff810016d1a7d8 ffff810016d1a7d8 ffffffff880a2c57 Call Trace: <ffffffff880a2c57>{:ext3:ext3_find_entry+224} <ffffffff8020c9fc>{do_lookup+139} <ffffffff8020c9fc>{do_lookup+139} <ffffffff802a2326>{debug_mutex_add_waiter+159} <ffffffff880a4756>{:ext3:ext3_lookup+43} <ffffffff8020ca3f>{do_lookup+206} <ffffffff802098b1>{__link_path_walk+2590} <ffffffff8020e6a7>{link_path_walk+92} <ffffffff8020c7fe>{do_path_lookup+633} <ffffffff802224de>{audit_getname+145} <ffffffff802249c9>{__user_walk_fd+55} <ffffffff802421cf>{vfs_lstat_fd+24} <ffffffff8022c337>{sys_newlstat+25} <ffffffff80262ea1>{tracesys+113} <ffffffff80262f01>{tracesys+209} Code: 0f 0b 68 e7 dd 0a 88 c2 7f 01 48 8b 04 24 48 89 44 24 08 66 RIP <ffffffff880a213c>{:ext3:dx_probe+331} RSP <ffff810041031a58> BUG: updatedb/19067, lock held at task exit time! [ffff810016d1a8b0] {inode_init_once} .. held by: updatedb:19067 [ffff810040231860, 134] ... acquired at: do_lookup+0x8b/0x188 Expected results: This should work as advertised! Additional info: None.
We'll look at this, but do you have any more information about how exactly to reproduce this? I use lvextend + ext2online regularly without problems.
Hi Stephen. One extra datapoint: after reboot, my filesystem was completely hosed. e2fsck -y took hours to complete, generated > 100 MB output. Upon completion, most files were corrupted. That sucked. This is what I did: 1. Filesystem was mounted. 2. I extended the partition with 'lvextend -l +1 /dev/xxx' 3. I ran 'ext2only /dev/xxx' That's it. That was on an up-to-date FC5 x86_64 system. From a cursory look at the crash, and given what e2fsck was complaining, I suspect htrees (aka. dir_index) is involved. But I have no hard data backing this up. Should I try to reproduce the problem?
Apologies for this, but I'm going to close this bug, as ext2online is deprecated in favor of resize2fs, which can also do online resizing. ext2online is no longer shipped with Fedora, at least as of FC6. -Eric