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

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

> 
> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> [...]
> > on can tell, what extactly is supported. Regaring the FS flags 
> > mentioned in my previous mail, I will add a `fs=5Fflags' field to 
> > extended=5Fpartition=5Finfo, that will look the same as fs=
> > 5Finfo::flags. 
> > (If 
> > also a free=5Fblocks would be added, then one should have enough 
> > information for resizing of partitions.)
> 
> 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_blocks' field is not what I'm thinking of, but rather a 
`minimal_fs_size'. 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.

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

CU, Ingo