> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote: > > > That doesn't have to be the case; in the end, the file system > > > itself > > > must be bothered with the question of the overhead of a partition > > > resize operation - only the file system can now if it needs more > > > space > > > to i.e. store the (now) fragmented file or something like this. > > It could defragment the partition before. :-P > > Honestly, I see the problem, but without knowing in advance how > > small > > a > > FS can become, it is very ugly to implement a GUI to let the user > > do > > the resizing. > > > > Maybe a `free=5Fblocks' field is not what I'm thinking of, but > > rather a > > `minimal=5Ffs=5Fsize'. I suspect most FSs can simply set that to > > the used > > size -- it least, if they are able to defragment or whatever is > > necessary to not use more space when being shrunk -- others may add > > a > > safety margin, that they can estimate best. > > Yes, that would probably the best way. > > > > Of course, we could just have a generic safety margin that would > > > be > > > suitable for all file systems, like there needs to be at least 3% > > > free > > > space in the new volume, or something like that. > > That's hard to do well in general. 3% doesn't sound much, but for a > > 35 > > GB disk it is 1+ GB, which I find not acceptable as granularity. > > Indeed, the file system should know it better, so it's best when it > handles that information. > I think I'll make a list of what's needed :-) Cool, do that! :-P CU, Ingo