Re: Facing the End ;-)

"Axel Dörfler" <[email protected]>
Newsgroups gmane.os.openbeos.storage
Message-ID <338331991-BeMail@nichtsnutz>
"Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.