On Mon, Jan 13, 2014 at 01:41:27PM -0700, Andreas Dilger wrote: > > Instead of adding a new location for the backup superblock at the > "end" of the disk (which is subject to change if the filesystem is > resized), what about using the last group that would otherwise have > a backup superblock with the "sparse_super" feature? That means > resizing the filesystem by some amount won't change the location of > the backup, and avoids the need to change all of the documentation > for how to find superblocks. That doesn't actually reduce the complexity. The two headaches with dealing with the resize is (a) when you grow the file system and add one or more new block groups, you need to release the blocks associated with backup superblock and block group descriptors, and then (b) when you shrink a file system and you remove one or more block groups, you need to relocate blocks where we need to put backup superblocks in the "new" last block group. Neither of these is a show stopper, but it's annoying since we need to implement (a) and (b) in resize2fs, and then in the kernel twice, once for the old-style online resize, and then again for the meta_bg style online resize. If we put the 2nd backup sueprblock in the last location where there is a sparse_super feature, we still have deal with both of these issues, and indeed it's actually a bit more of a headache to calculate the block group which satisfies this constraint. In addition, it decreases slihgtly the range of contiguous data blocks. (Putting the backup superblock at the very end of the file system is the best from this perspective, but it increases the complexity headache even more.) What I'll probably do for now is to simply not support online resize for the newly renamed "super sparse" feature, since for my use case, which is for things like SMR disks, we're not going to be resizing them anyway. If we want to use this mode for RAID 5 arrays, then we will have to get the resizing support working for the new "super sparse" mode. - Ted -- 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
