On Sun, 1 Jul 2007 08:30:54 -0400 Theodore Tso <tytso@xxxxxxx> wrote: > It was the intention that META_BG include allowing the bitmap and > inode tables to range anywhere outside of the block group, but that > never got coded. It would be confusing though if we relaxed it > withotu adding a feature bit, and I agree that we might as well use > overload the BIG_BG group to indicate this feature. > > The fact that BIG_BG requires contiguous blocks for the bitmaps when > they exceed blocksize*8 blocks still concerns me a minor amount, and Is your concern due to being unable to find contiguous block in the case that a bad disk area is in one of the bitmap blocks? One thing we can do is try to search for another set of contiguous blocks and if we fail to find one, we can flag the block group and move to an indirect block approach to allocating the bitmaps. At this point, we do lose some of the performance benefits of BIG_BG, but we would still be able to use the block group. > given the hopeful inclusion of kernel patches that allow blocksize > One thing that concerns me about blocksize larger than page size is that it requires to much planing from the person creating the filesystem. While larger blocksizes does address some of the issues of the block group size limits, it does so in a less flexible manner. With something like BIG_BG, we can provide larger extents for large files while still keeping disk space consumption under control with small files. > pagesize. Furthermore, I still wonder whether we will want to make > blockgroups that much bigger (since reducing the allocation groups is > not necessarily a smart thing; we will need to do some benchmarks with > filesystem aging to see how this affects antifragmentation efforts), > but the complexity engenered by adding BIG_BG isn't that bad (again, > my only concern is with the contiguous bitmap blocks requirements). Point take... I'll do some aged filesystem test to see how if are some real benefits to be gain in reducing fragmentation. > > - Ted -JRS - 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
