[openbeosstorage] Re: Amiga RDB

> > > 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.

What about making all three (both reserved chunks AND unreserved space) 
virtual partitons? This is a different use of virtual partitions than we 
had in the previous framework; we'd be using the more general 
partitioning scheme to fit a slightly different partitoning scheme 
cleanly into the whole framework in a standard manner, rather than 
making accomodations for a suboptimal framework. 

From what it sounds like at least, a partition with reserved space at 
the start and end is effectively subpartitioned into three chunks: 
reserved partitions at the start and back, and unreserved data for the 
filesystem in the middle. So they'd be virtual in the sense that the 
existence of reserved space isn't technically intended to be used as a 
partitioning mechanism, but effectively that's what's being done. 
Presenting them as "virtual" partitions simply allows the common 
partitioning interface to be used instead of tacking on a new one (or 
ignoring the problem all together, which is perhaps an arguably valid 
idea :-). 

As a side benefit, the virtual partition method would also allow us to 
easily support resizing and/or deleting the reserved space.

> > > 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.

So, you'd want to make access to partitionable space go through a flat, 
index-based mechanism, and then map the returned extents into the 
appropriate partitions by hand?

> 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.

I still think having the virtual partitions would enable DriveSetup to 
present a more accurate representation of physical reality, though. 

-Tyler

Other related posts: