On Nov 11, 2008 11:09 -0500, Michael B. Trausch wrote: > I do have an ltrace up and online at: > > http://fd0man.theunixplace.com/tune2fs.ltrace.bz2 > > The bzip2 file is 44 MB, and the uncompressed text is _huge_ (about 3 > GB). This is a two hour run of "tune2fs -I 256 /dev/sdb" on an > external 250 GB (235 GiB) drive formatted with the ext3 filesystem. > I aborted the tune2fs run after 2 hours, though I am sure it would have > run for far longer. Hopefully, this will give some insight as to what > the problem might be. It looks like the code is just spending hours looking at the bitmaps, but I have no idea why: ext2fs_test_generic_bitmap(0x1f3d020, 0xfa31e1, 1, 0, 0x1f418b0) = 0 ext2fs_test_generic_bitmap(0x1f3d020, 0xfa31e2, 2, 1, 0x1f418b0) = 0 ext2fs_test_generic_bitmap(0x1f3d020, 0xfa31e3, 4, 2, 0x1f418b0) = 0 ext2fs_test_generic_bitmap(0x1f3d020, 0xfa31e4, 8, 3, 0x1f418b0) = 0 ext2fs_test_generic_bitmap(0x1f3d020, 0xfa31e5, 16, 4, 0x1f418b0) = 0 ext2fs_test_generic_bitmap(0x1f3d020, 0xfa31e6, 32, 5, 0x1f418b0) = 0 ext2fs_test_generic_bitmap(0x1f3d020, 0xfa31e7, 64, 6, 0x1f418b0) = 0 ext2fs_test_generic_bitmap(0x1f3d020, 0xfa31e8, 128, 7, 0x1f418b0) = 0 Possibly the code is very inefficient and is scanning every bit in the bitmap individually to see if an inode is in use, instead of doing something fast like just checking an entire bitmap word == 0 and skipping it. Unfortunately, ltrace doesn't show what is calling this code, so a stack trace is needed from GDB. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
