On Mon, Jan 31, 2022, at 11:26 PM, Zygo Blaxell wrote: > On Sat, Jan 29, 2022 at 10:53:00AM +0100, Goffredo Baroncelli wrote:
> It does suck that the kernel handles resizing below the minimum size of > the filesystem so badly; however, even if it rejected the resize request > cleanly with an error, it's not necessarily a good idea to attempt it. > Pushing the lower limits of what is possible in resize to save a handful > of GB is asking for trouble. It's far better to overestimate generously > than to underestimate the minimum size. Yeah there's an inherent conflict with online shrink: the longer the time needed to relocate bg's, the more unpredictable operations can occur during that time to thwart any original estimations made about the shrink operation. I wondered a bit ago about a shrink API that takes shrink size as a suggestion rather than as a definite, and then the file system does the best job it can. Either this API reports actual shrink size once it completes, or the requesting program needs to know to call BTRFS_IOC_FS_INFO and BTRFS_IOC_DEV_INFO to know the actual size. This hypothetical API could have boundaries outside of which if the kernel code estimates it's going to fall short of, could trigger a cancel of the shrink. This could be size or time based. e.g. BTRFS_IOC_RESIZE_BEST (effort). -- Chris Murphy
