On Sat, May 23, 2015 at 08:27:50PM -0400, Phillip Susi wrote: > > On 05/23/2015 07:36 PM, Theodore Ts'o wrote: > > Figuring out the minimum size in a way where we don't screw up and > > pick a number too _low_ is tricky, because if resize2fs aborts in > > the middle, we can end up with a corrupted file system. > > Why is it hard? Why isn't it simply the number of used blocks, or the > highest fixed metadata block, whichever is higher? The amount of space needed for metadata blocks change depending on how many block groups you have, and as you shrink the block groups, the amount of space you need the metadata blocks shrink. You might also need some of the extra block groups to make sure you have enough inodes for all of the inodes in the system. Also, we can't necessarily use all of the space right away; for example, the inode table for block group #25 lives in block group #16. If we are shrinking the file system such that block groups #20 through #25 will no longer be present, we can't use the inode space for those block groups until *after* the resize has completed successfully, since we can only free up those blocks after we have made sure we have evacuated all of the inodes to other parts of the inode table. > > I'm going to guess the problem has to do with the reserved space > > needed so that resize works correctly, and the amount of reserved > > Reserved for what? Reserved for additional block group descriptors when we are growing the file system. - 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
