Bug 676683

Hm, in my testing, I didn't see anything like 83%.  Occasional jumps to maybe 10% during pass 4 (Updating inode references) but that's it... Different CPU, smaller fs though.

If this is something you can repeat (?) it might be worth doing some profiling to see where it's spending time?

Running with -p would at least show you which phase it's in when this happens.

FWIW, this is probably best reported upstream, since it's not unique to Fedora.

I don't know that I'll be able to spend much time on this; fs shrink performance has never really been on the radar...  for that reason I think I will close this as UPSTREAM; if you can report it to the linux-ext4.org list, that would probably be good.  I always feel bad about doing that, but sometimes it's best to set realistic expectations.  :)

(If you're able to do some profiling & identify where time is being spent, feel free to add updates, if your further investigation points to something obvious or fixable, I'll take another look)

I can reproduce the problem.

The original filesystem has been shrunk, and I did not save a pre-shrink copy.  However, I created a new ext3 of nearly the same original size (153GB), copied ("cp -r") the entire contents as files from the shrunk system to the new system, and resized the new system similarly to the original shrink.  Pass 3, Scanning inode table, is CPU-limited.

I used different hardware for the second resize shrink: a 250GB external drive with USB2.0 interface on a 2.5GHz Athlon II x86_64 with 4GB DDR2 RAM.  I ran the second resize shrink with active oprofile-0.9.6 on Fedora 14, kernel-2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50 UTC 2010.

The output from the resize was:
-----
# e2fsck -f /dev/sdc2
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
test-resize: 1071971/9863168 files (0.1% non-contiguous), 21597266/39423744 blocks
# time resize2fs -p /dev/sdc2 91956153K
resize2fs 1.41.12 (17-May-2010)
Resizing the filesystem on /dev/sdc2 to 22989038 (4k) blocks.
Begin pass 2 (max = 7024795)
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 1204)
Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 62998)
Updating inode references     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/sdc2 is now 22989038 blocks long.


real	69m52.167s
user	26m29.431s
sys	2m3.456s

# 
-----


The opreport from oprofile was:
-----
# opreport -l image:/sbin/resize2fs
Overflow stats not available
CPU: AMD64 processors, speed 2499.56 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 100000
samples  %        symbol name
31677    55.9437  ext2fs_extent_translate
11008    19.4409  resize_fs
9302     16.4280  process_block
2443      4.3145  get_new_block
1341      2.3683  ext2fs_add_extent_entry
450       0.7947  check_and_change_inodes
212       0.3744  resize_progress_func
159       0.2808  ext2fs_progress_update
26        0.0459  mark_table_blocks
4         0.0071  progress_callback
1         0.0018  ext2fs_iterate_extent

# opreport
Overflow stats not available
CPU: AMD64 processors, speed 2499.56 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 100000
CPU_CLK_UNHALT...|
  samples|      %|
------------------
 38686670 75.1753 libext2fs.so.2.4
  8991168 17.4715 no-vmlinux
   604698  1.1750 libc-2.13.so
   526096  1.0223 libpixman-1.so.0.18.4
   283113  0.5501 libgklayout.so
   176661  0.3433 libxpcom_core.so
   175469  0.3410 Xorg

# 
-----

Because it is somewhat large, I will attach the (annotated) output from "vmstat 5" during the resize2fs, instead of displaying it inline here.

Created attachment 478170 [details]
output from "vmstat 5" during resize2fs

Output from vmstat, with annotations marking the Pass of resize2fs.

I reported this to linux-ext4.org.