Bug 197128 - ext2online corrupts filesystem
Summary: ext2online corrupts filesystem
Alias: None
Product: Fedora
Classification: Fedora
Component: e2fsprogs
Version: 5
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Eric Sandeen
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-06-28 18:06 UTC by Philippe Troin
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2007-09-11 13:37:09 UTC

Attachments (Terms of Use)

Description Philippe Troin 2006-06-28 18:06:36 UTC
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):

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,
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
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}
       <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:

Comment 1 Stephen Tweedie 2006-06-28 21:43:40 UTC
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.

Comment 2 Philippe Troin 2006-06-29 23:01:07 UTC
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?

Comment 3 Eric Sandeen 2007-09-11 13:37:09 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.