On Fri, Jul 15, 2022 at 11:35:18AM +0200, Jan Kara wrote: > > available for the filesystem having an “odd” size. Our preference is for > > the utilities to silently fix the fs size down to the nearest “safe” size > > rather than get sporadic errors. I had submitted a patch for resize2fs > > that rounds the fs target size down to the nearest cluster boundary. In > > principle it’s similar to the size-rounding that is done now for 4K > > blocks. Using updated e2fsprogs isn’t mandatory for using ext4 in the > > newer kernels, so making the kernel safe(r) for bigalloc resizes seems > > like a good idea. > > I see. Honestly, doing automatic "fixups" of passed arguments to syscalls / > ioctls has bitten us more than once in the past. That's why I'm cautious > about that. It seems convenient initially but then when contraints change > (e.g. you'd want to be rounding to a different number) you suddently find > you have no way to extend the API without breaking some userspace. That's > why I prefer to put these "rounding convenience" functions into userspace. > > That being said I don't feel too strongly about this particular case so I > guess I'll defer the final decision about the policy to Ted. In this particular case, a file system whose size is not a multiple of cluster size is never going to be valid, so having the resize ioctl round down the requested size to largest valid size seems to be a safe (and useful) thing to do. - Ted
