There are some ways that this can be mitigated (you can give options to mke2fs to use a 4k block size, enable 64k blocksize, and force a larger journal size), but if the file system has some files placed in the small file system, the block placement of the small file system will not be optimal after the file system is blown up to a large size. Is there some place which is recommending this anti-pattern, or otherwise causing people to think this is a good idea? So this idea of "drop a small file system on a device" and then blowing it up to a huge size is a Really, REALLY, REALLY bad idea. But like the 1k block size, this limits the maximuim size that is supported by the base file system, and it is not at all simple to change the fundamental aspects of the file system so that the file system is (a) scalable, and (b) performant. We also don't enable 64-bit block numbers, since this increases metadata overhead. But both of these changes have significant performance impacts - which might not matter if the file system is meant for a small, slow USB thumb drive, but if you are trying to use this for a higher performance system - you'll be sorry. We also reduce the size of the ext4 journal, to reduce file system overhead. In this case, with a small file system, we use a 1k block size, to reduce space wasted by internal fragmentation. When you then blow it up by a thousand of times, or more, those hueristics will be not be correct. That's because mke2fs will be making changes based on hueristics based on the size of the file system. Even when it "works", the performance is going to be terrible. Well, then don't do that!" Trying to resize a file system from super-tiny to super-large is never going to end well. "Doctor, doctor, it hurts when I do that. I will look into this and try to figure out what is going on, and address this.įundamentally, though, the fix from your perspective is the same as #50. From that perspective, thank you for the bug report. You're right that resize2fs should either not issue the warnings, or reject the resize.
0 kommentar(er)
