Re: BDiskSystem::Supports*()/Validate*()

"Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]>
Newsgroups gmane.os.openbeos.storage
Message-ID <3814724868-BeMail@graete>
On Mon, 21 Jul 2003 00:14:33 -0700 Tyler Dauwalder <tyler-cyCl/[email protected]
> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.