Description of problem: When creating a filesystem with mke2fs without explicit block count specification, mke2fs is examining the block count for the device. However on PPC64 the result is often lower (always divisible by 16) than actual block count. Version-Release number of selected component (if applicable): e2fsprogs-1.39-33.el5.ppc How reproducible: Always Steps to Reproduce: 1. dd if=/dev/zero of=/tmp/loop.bin count=1000 bs=4096 2. yes | mke2fs -T ext3 -b 4096 -m4 /tmp/loop.bin Actual results: ... 512 inodes, 992 blocks 39 blocks (3.93%) reserved for the super user ... Expected results: ... 512 inodes, 1000 blocks 40 blocks (4.00%) reserved for the super user ... Additional info: Happens on PowerPC only. Workaround: Specify the block count: yes | mke2fs -T ext3 -b 4096 -m4 /tmp/loop.bin 1000
Somehow I missed seeing this one come in. If you have the box handy can you strace mke2fs so I can see what calls it's making? Otherwise I'll grab a box from beaker & see what I can see. -Eric
Ok, this is intentional, from this code in mkfs: fs_param.s_blocks_count = dev_size; if (sys_page_size > EXT2_BLOCK_SIZE(&fs_param)) fs_param.s_blocks_count &= ~((sys_page_size / EXT2_BLOCK_SIZE(&fs_param))-1); which came from this commit: commit a7ccdff8e128c24564011d760a996496b0a981b3 Author: Theodore Ts'o <tytso> Date: Tue Jul 8 18:03:48 2003 -0400 In mke2fs and resize2fs, round the default size of the filesystem to be an even multiple of the pagesize to work around a potential Linux kernel bug. Use the testio manager in mke2fs if CONFIG_TESTIO_DEBUG is set. The kernel bug isn't explained, but this seems like a really low impact bug; on ppc64 you'd lose less than 64k due to the rounding. I don't think this is something we need to mess with at this point in the RHEL5 lifecycle. If the behavior is causing serious issues for someone, please re-open with the rationale for further work on this. Thanks, -Eric