On Sat, May 23, 2015 at 05:18:41PM -0400, Phillip Susi wrote: > > So I have a filesystem with nothing beyond group 16 used ( including > metadata ), so it should be able to shrink to ~524288 blocks, yet > resize2fs claims the minimum size is 770083 blocks. Resize debug output > follows: 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. I have continued to severely regret accepting the patch that calculates the minimum size necessary, because it's *hard* to get it right, and if it's too aggressive, users lose data, and get angry, and if it's too liberal, then users whine. 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 space needed drops as we decrease the nmber of block groups. So if you start with a very large file system, and then try to shrink it down to minimum size, you may need to run resize2fs -M multiple times. Which to be honest, is just fine as far as I'm concerned, because I've been trying to strongly discourage the use of resize2fs -M in the first place, because it tends to leave a highly non-optimal 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
