FreeLists / openbeosstorage / [openbeosstorage] Re: Amiga RDB

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
[...]
> > > > > > I'm a bit uncertain, whether I start to dislike the
> > > > > > BPartitionableSpace
> > > > > > objects. In the case of this partitioning system they would
> > > > > > certainly
> > > > > > respect the reserved space attached to the partitions and 
> > > > > > thus
> > > > > > make
> > > > > > DriveSetup think, that the partitions can't be moved only a
> > > > > > short
> > > > > > distance, as that would invade non-partitionable space.
> > > > > 
> > > > > That reserved space would have to belong to the partition 
> > > > > itself,
> > > > > I
> > > > > think. But if you start to dislike the BPartitionableSpace
> > > > > objects,
> > > > > I
> > > > > can't stop you ;-)
> > > > 
> > > > Hehe. I'm still waiting for a plea from Tyler to keep them. :-P
> > > 
> > > If anyone has a better idea, I'm willing to hear it out. :-P :-)
> > >
> > > Why not make the non-reserved space a virtual sub-partition of 
> > > the
> > > actual partition? Then you could still move the entire partition
> > > around, reserved space and all, while respecting the 
> > > reservations.
> > 
> > That would be a solution only, if the partition in question
> > accommodates subpartitions, what, according to Axel, the RDB 
> > doesn't
> > natively support (we would provide nesting of partitioning systems
> > though). In case of a file system to me it doesn't seem to work 
> > very
> > well, for we would then have both, subpartitions and a file system. 
> > We
> > couldn't simply publish the whole partition as a device.
> 
> I'm not sure I see where the problem is coming from. The file system 
> would then live in the virtual sub-partition, which does not really 
> exist on the physical hardware, but is implemented solely in the 
> disk_device_manager add-ons. I.e., when an RDB partition with 
> reserved 
> space is discovered, that partition would publish a virtual child 
> partition of the appropriate, non-reserved size, and disallow 
> allocation of any of the reserved space for anything else.

Sorry, I obviously misread what you wrote before, though re-reading it 
now, it is very clear. :-)
I thought, you would want to make the reserved space a virtual 
subpartition.

> > A similar problem occurs when we explicitly support reserved blocks 
> > at
> > the beginning and end of a partition in the API. Although then we 
> > can
> > at least be sure that there won't be a reserved subpartition in the
> > middle of a partition. The ugliness with the publishing of the 
> > device
> > could be solved by having the reserved space live before/after and 
> > not
> > at the beginning/end of the partition. But then the handling of 
> > child
> > partitions becomes less nice.
> 
> Again, if you just use a nested (but fake) child partition, there's 
> no 
> need to publish the entire partition. Just publish the virtual, 
> non-reserved space as a device. It's still just a contiguous chunk of 
> space on the device, so I don't see where any ugliness would come 
> from.

Just from my inability to read properly. :-)

> > But rather than wasting another 16 bytes per partition, I'd like to
> > ignore those reserved blocks in the API and hope that this feature 
> > is
> > virtually unused. The partition module would take care, that no bad
> > things happen in cases where it is used, and DriveSetup would 
> > visualize
> > such a setting slightly suboptimal. Well, and BPartitionableSpaces
> > would suck...
> 
> I think I'm okay with this, too, but I think the virtual partition 
> idea 
> is cleaner (at least, until you somehow convince me it won't work. :-
> )

I don't see any reason why it wouldn't work. :-)

Nevertheless I'm not too happy with introducing virtual partition here. 
One beautiful aspect of unifying sessions and partitions was, that we 
could get rid of those dumb virtual sessions and partitions, which we 
only needed to make the real world fit into our obviously suboptimal 
framework.

> > Maybe it's a good idea to remove them from the BPartition anyway. 
> > Mind
> > you, resizing/moving a partition will also always affect sibling
> > partitionable spaces (up to four in case of moving), which might be 
> > a
> > bit hairy to handle. Since the information the BPartitionableSpaces
> > provide are of interest only, if one is going to modify the 
> > partition
> > layout (and would only waste resources otherwise), it might make 
> > more
> > sense to retrieve them on request only. E.g. via a method
> > BPartition::GetPartitionableSpaces(BObjectList<BPartitionableSpace>
> >  *
> > spaces). Or maybe even more consequent:
> > BPartition::GetPartitioningInfo(BPartitioningInfo *info), where
> > BPartioningInfo could not only know, which are the free spaces, but
> > also which space is assigned to which subpartition. This would also
> > solve the problem with the RDB's reserved space at the beginning/
> > end 
> > of
> > partitions, since the BPartitioningInfo would consider the complete
> > space occupied by a subpartition.
> 
> Well, either idea seems perfectly reasonable to me, particularly 
> given 
> the strong distaste everyone seems to have for my lovely 
> BPartitionableSpace objects. :-( ;-)

Ohh, poor Tyler... ;-)

Seriously, I don't dislike the BPartitionableSpace objects, but I would 
at least want to move them out of the BPartition objects, making them 
available on request only. And given the little info the bear, a 
BPartitioningInfo with a method bool GetPartitionableSpaceAt(int32 
index, off_t *position, off_t *size) should be sufficient.

Note, that the `annihiliation' of BPartitionableSpace by introducing a 
BPartitioningInfo does not speak against making the non-reserved space 
of an Amiga RDB partition a virtual subpartition. Although it wouldn't 
be needed anymore, and that fact doesn't make me like the idea more.

CU, Ingo