FreeLists / openbeosstorage / [openbeosstorage] Re: BDiskSystem::Supports*()/Validate*()

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

On Mon, 28 Jul 2003 09:35:10 -0700 Tyler Dauwalder <tyler@xxxxxxxxxxxxx
> wrote:
> 
> On 2003-07-27 at 16:13:33 [-0700], you wrote:
> > On Sun, 27 Jul 2003 11:09:18 +0200 CEST "Axel Dörfler" <axeld@pinc-
> > software.de> wrote:
> > > "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > [...]
> > > > > rarely needed, I think it would be a good idea to have the
> > > > > ContentSize() feature in there if we're going to support
> > > > > non-destructive enlarging even when the contents of the 
> > > > > partition
> > > > > cannot (and are not) enlarged.
> > > > OK, it's no problem to add it. The question is then, whether we
> > > > want
> > > > to
> > > > allow resizing the contents individually
> > > > (BPartition::ResizeContents(off_t)), or at least allow to pass 
> > > > both
> > > > size and content size to Resize():
> > > > 
> > > >     status_t Resize(off_t size, off_t contentSize);
> > > > 
> > > > CanResize() and ValidateResize() would need to be adjusted
> > > > accordingly.
> > > > Against separating the features speaks, that it's more work for 
> > > > the
> > > > API
> > > > user, since they must take care of the order of applying the 
> > > > resize
> > > > operations (contents, partition when shrinking, the other way
> > > > around
> > > > when enlarging).
> > > 
> > > I think it would be okay if contentSize had a default parameter 
> > > in
> > > which case it'll be the same as size. OTOH I don't think those
> > > changes
> > > are worth the effort, since I cannot really imagine a situation 
> > > where
> > > you want to do that.
> > 
> > Do you mean all of the new suggestions or only the one for 
> > Resize()? 
> 
> I believe he is just referring to enlarging a partition without 
> enlarging its contents.
>
> > As
> > I interpreted the vibrations on the list, ContentType() is liked, 
> > since
> > it allows us to deal more sensibly with non-resizable partition
> > contents on otherwise resizable partitions (not nuking it as long 
> > as
> > the partition size shrinks smaller than the content size). 
> 
> You mean "doesn't shrink", don't you?

Sure. :-)

> > Resize()
> > could remain unchanged, CanResize() too (save for providing a 
> > default
> > parameter for `canResizeContents'), but, I think, ValidateResize()
> > should nevertheless have an optional parameter `off_t *contentSize'
> > instead of `bool resizeContents'. If a pointer is not supplied, the
> > pointed to variable would not need to be set by the caller; the 
> > system
> > returns in it the size the contents can be resized to. It would be 
> > the
> > current content size, if the respective disk system does not 
> > support
> > resizing, a suitable value otherwise. The caller can then pass true 
> > for
> > the `resizeContents' parameter of Resize(), when the value is equal 
> > to
> > the current one, which nukes the contents, if the given partition 
> > size
> > is too small to have the partition contain the contents, but leave 
> > it
> > untouched otherwise.
> 
> I think that's a good way of handling the described semantics, but I 
> also think Axel has a good point: why would you want to resize a 
> partition but not its contents?

E.g. if you're not interested in the contents anymore (resizing the 
contents probably takes quite some time, which is wasted, if you want 
to ditch it anyway). Currently Resize() is implemented so that, if you 
pass false for `resizeContents', the contents is nuked. I think, the 
start of the discussion was, that enlarging the partition wouldn't 
destroy the contents, so that one could actually keep it.

> Having ContentSize() around in case 
> such a thing happens due to someone else's tools is probably a good 
> idea, but doesn't it seem more natural to always resize the contents 
> with the partition?

Yep, I think, it is. Maybe it's a good idea to introduce a 
BPartition::Uninitialize(). Then, if you aren't interested in the 
partition's contents, you would call Unitialize() before Resize(). 
Resize() wouldn't have the `resizeContents' parameter anymore, since it 
would always resize the contents. The question is, what should be done, 
if the content disk system doesn't support resizing. I guess, it would 
be consequent to just fail then.

BTW, Move() could work similar: The `bool force' parameter could be 
dropped and the method would fail, if any descendant's contents could 
not be moved. The API user would need to invoke Uninitialize() on the 
concerned partitions before calling Move().

[...]
> > BTW, I was hoping to implement the job stuff and the first bits of
> > physical partition manipulation this weekend, but unfortunately had 
> > no
> > time to do anything. :-( I did a small biking tour today and used 
> > up
> > the better part of yesterday to get my bicycle into a clean and 
> > well-
> > working state (which two hours of riding in the rain pretty much 
> > undid
> > :-( ). Anyway, I hope to get something done over the course of the
> > week.
> 
> Good for you! I should really get my bike out sometime before the 
> weather goes bad here again. I spent the weekend writing a paper and 
> wrangling with LaTeX, I'm afraid, but I have been listening to mp3s 
> off 
> of UDF cdroms. :-)

Under BeOS, I hope! :-))

CU, Ingo