Theodore Tso wrote:
On Fri, Jun 09, 2006 at 11:11:31PM -0400, Jeff Garzik wrote:
It's an example of ext2 being bandaided to do something it was never
originally designed to do. If online resizing had been planned from the
start, allocating new inode tables on the fly would be trivial, as it is
in JFS/NTFS/...
And once again this has *nothing* to do with inode allocation, or
dynamic allocation of inode tables. Your "performance issue" has to
do with a difference in blocksizes. If you ext2/3 to pass your silly
test, then upgrade to the latest e2fsprogs and install the following
/etc/mke2fs.conf:
WTF? In none of my examples did block size ever change. In none of my
examples was block size ever mentioned as a factor.
Inode density was demonstrably different in the resize vs. mkfs cases.
And online resize -obviously- imposes a limit on inode density, by
locking inodes-per-group at fs creation time. Dynamic allocation of
inode tables would permit dynamic sizing of inode tables based on
current needs, rather than needs determined at fs creation time.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
