[openbeosstorage] Re: Facing the End ;-)
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sun, 16 Feb 2003 01:17:23 CET (+0100)
>
> "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
Other related posts:
