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

On Mon, 21 Jul 2003 00:14:33 -0700 Tyler Dauwalder <tyler@xxxxxxxxxxxxx
> wrote:
> On 2003-07-18 at 07:41:35 [-0700], you wrote:
> > So BPartition::Resize() needs something like a `bool force' 
> > parameter,
> > indicating, that it shall not fail, when resizing the content 
> > fails; 
> > or
> > maybe better `bool resizeContents' specifying whether or not to 
> > resize
> > the contents. At any rate that would make the semantics of 
> > CanResize()
> > a bit confusing, I think (since it will just return false, although
> > calling Resize() is possible). Another parameter might be useful:
> > 
> >   bool CanResize(bool *canResizeContents, bool *whileMounted = 
> > NULL);
> > 
> > The method would return, whether resizing is possible at all,
> > canResizeContents would additionally tell you, whether the 
> > contained
> > disk system can be resized as well, and if that is the case and the
> > disk system is a file system, then whileMounted would provide the
> > obvious information...
> 
> So CanResize() would return whether the parent allowed resizing the 
> child, and canResizeContents would say whether the child could resize 
> itself as well, correct?

Exactly. :-)

[...]
> > Thus in principle also Move() should have something like a `bool 
> > force'
> > parameter; or maybe `uint32 options' where options can be
> > B_MOVE_PARTITION_ALL, B_MOVE_PARTITION_FORCE,
> > B_MOVE_PARTITION_IGNORE_CONTENTS. 
> 
> Does B_MOVE_PARITION_ALL succeed iff you can move all partitions?

Yep.

> And 
> is FORCE then "move as many as you can, destroying those that say 
> they 
> can't be moved"

All partitions claiming, that they can be moved in principle, are tried 
to be moved. If moving any of them fails, the complete Move() reports 
an error. So it's `move all partitions whose disk systems reported them 
as movable'. Since the respective syscall for Move() will internally do 
the equivalent of a ValidateMove() first, the shadow partitions won't 
be touched, if it fails.

> and IGNORE "just move it and wipe out the contents"?

That would have the same semantics as deleting the partition and re-
creating it at the new position. Alternatively the partition could be 
moved indeed, which would save all descendants, that don't use absolute 
addressing. I changed the KDiskSystem::SupportsMoving() parameter from 
`whileMounted' to `isNoOp', which is equivalent in case of file 
systems, but gives more info for partitioning systems. So, all 
descendants for which moving is a no-op would survive. Don't know, if 
that is desired though -- one would probably use FORCE in this case 
anyway.

I'm not even sure, that IGNORE would be used in practice. How I 
imagined DriveSetup to work when the user moves a partition, would be 
to do a ValidateMove() to find out whether descendant partitions are 
movable or not, ask the user something like `Partitions X, Y, Z are not 
movable. Their data will be destroyed, when proceeding. [Nuke Them] 
[[Cancel]]'. So, FORCE would be used, otherwise (if all descendants are 
movable) ALL. Hence I only added a `bool force' parameter. But I can 
change that, if you think, that other variant is better.

> > For CanMove() I'd think of:
> > 
> >   bool CanMove(bool *canMoveContents, bool *whileMounted = NULL);
> > 
> > canMoveContents will be set to false, if the contents of any 
> > descendant
> > cannot be moved. If the partition does contain a partitioning 
> > system,
> > I'm not sure, what the best semantics would be for whileMounted. It
> > could be that all descendants can remain mounted, or it could 
> > simply 
> > be
> > ignored in this case.
> > 
> > Instead of `canMoveContents' (or additionally) a `BObjectList<
> > BPartition> *descendantsWithUnmovableContents' parameter could be
> > added. Then DriveSetup could also find out, which partitions' 
> > contents
> > would become invalid, when moving the partition is `forced'.
> 
> Having the extra info provided by the list might be nice. I think I 
> would favor that method. Perhaps two lists: MovableWhileMounted, and 
> Unmovable. Those movable only with unmounting are then easily 
> determined as well (or instead make the second list 
> MovableOnlyIfUnmounted, or something to that degree).

Yes, that's much better than the somewhat inexpressive whileMounted.

> > Finally there's BPartition::ValidateMove(), which is a bit tricky. 
> > I
> > think, it would be quite difficult to try to negotiate a value that 
> > all
> > affected disk systems are happy with. So I would only try to fine a
> > value acceptable for the partitioning system responsible for the
> > partition in question and its contained disk system, and fail after 
> > one
> > or two unsuccessful iterations. For the descendants I would only 
> > ask,
> > if they are OK with the new value and just fail, if any of them is 
> > not.
> 
> Sounds fair. We could always try something more thorough if we ever 
> find ourselves with lots of free time on our hands. :-)

Hehe, if that will ever happen... ;-)

CU, Ingo

Other related posts: