On Sun, Feb 27, 2011 at 11:59 PM, Ted Ts'o <tytso@xxxxxxx> wrote: > On Sat, Feb 26, 2011 at 09:20:55AM +0200, Amir Goldstein wrote: >> Just to be clear, my alternative suggestion to on-disk format change was: >> >> __u32 s_log_block_size; /* Block size */ >> - __s32 s_log_frag_size; /* Fragment size */ >> + __s32 s_log_cluster_size; /* Allocation cluster size */ >> - __u32 s_blocks_per_group; /* # Blocks per group */ >> + __u32 s_clusters_per_group; /* # Clusters per group */ >> - __u32 s_frags_per_group; /* # Fragments per group */ >> + __u32 s_blocks_per_group; /* # Blocks per group */ >> __u32 s_inodes_per_group; /* # Inodes per group */ >> >> This way, old kernels see a sane value in what used to be >> s_blocks_per_group (32K) and new kernels (even without the BIGALLOC >> feature) make sure to write correct values in both new >> s_blocks_per_group and s_clusters_per_group (old s_blocks_per_group) > > Unfortunately, that's likely to confuse old kernels even more, since > s_blocks_per_group is used to calculate the number of block groups, > i.e. s_blocks_count / s_blocks_per_group. In BIGALLOC mode, the > number of block groups go down, and so if we change s_blocks_per_group > to s_clusters_per_group, it's likely to cause much mischief, for > example in ext4_check_descriptors(). > I see..., I guess if we bite the bullet and "waste" an alloc cluster for every block bitmap and every inode bitmap, than we could also "waste" some disk space on dummy group descriptors to leave old kernels in blissful ignorance (mischief rules!). Another comment about the design: It only states that ext4_map_blocks() and downstream functions need to be aware of the new allocation rules, but I suspect that ext4_truncate() and downstream functions will also need to take the new rules into account (i.e. don't 'free' a cluster until all blocks have been freed). -- 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
