[openbeosstorage] Re: BDiskSystem::Supports*()/Validate*()
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Mon, 21 Jul 2003 13:58:57 +0200 CEST
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:
