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.