On Sep 25, 2008 20:10 -0500, Jose R. Santos wrote: > One way to get around this is to implement the exact opposite of what I > proposed earlier and have a block group with no inode tables. If we do > a 1:1 distribution of inode per block and don't allocate inodes tables > for a series of block groups within a flexbg we could later on attempt > to allocate new inode tables when we run out of inodes. If we leave > holes in the inode numbers for the missing inode tables, adding new > inode tables in these block groups would not require any inode > renumbering. This also does not break the current inode allocator > which would be a good thing. This should be even simpler to implement > than the previous proposal. The drawbacks are that when allocating a > new inode table, the 1:1 distribution of inode per block would mean > that we need to find a bigger chunk on contiguous blocks to since we > have bigger inode tables per block group. Since the current inode > allocator tries to keep a 10% of blocks in a flexbg free, finding > contiguous blocks may not be a really big issue. Another issue is 64bit > filesystem if we use a 1:1 scheme. > > This would be like uninitialized inode tables with the added steps of > finding free blocks, allocating a new inode and zeroing the newly > created inode table. Since we could chose to allocate a new inode > table on a flexbg with the most free blocks, this could keep filesystem > meta-data/data layout consistently close together to maintain > predictable performance. This option also has no overhead compared to > the previous proposal. The problem with leaving gaps in the itable is that this needs the filesystem to be created in this manner in the first place, while adding them at the end can be done to any filesystem. If we are preparing the filesystem in advance for this we could just reserve enough GDT space too (as online resize already does to some extent).. 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
