[openbeosstorage] Re: Facing the End ;-)

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

Adios...
   Axel.

Other related posts: