FreeLists / openbeosstorage / [openbeosstorage] Re: Facing the End ;-)

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

> "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