[openbeosstorage] Re: Partitionable Space (was re: Amiga RDB)
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Tue, 27 May 2003 16:10:30 +0200 CEST
Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> > [...]
> > > > 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?
> >
> > I'm not sure, if I get, what you mean. The
> > GetPartitionableSpaceAt()
> > returns the same info as BPartition::PartitionableSpaceAt()->
> > Offset()/
> > Size().
>
> I mean, you're wanting a single, linear mapping of partitionable
> space
> over each device, correct? I.e., a single BPartitioningInfo object
> per
> device.
No, one per partition. I thought that was clear from the fact, that the
proposed getter method would live in BPartition. :-P
> Why not just BPartition::PartitionableSpaceAt(int32 index, off_t
> *position, off_t *size) then? Pulling that information out of the
> partition hierarchy when it's just going to need to be mapped right
> back in again doesn't make any sense to me. What does that gain?
If one would flatten that information, that would indeed be a drawback.
Though, that's not what I had in mind. :-)
What I was thinking of, is to make the partitionable space information
available on request only. That is it would not be stored in the
BPartition object, but retrieved from the kernel when the method is
invoked. A BPartition::PartitionableSpaceAt(int32, off_t*, off_t*)
could do that too, it would be less efficient than getting a
BPartitioningInfo at once. In practice that probably doesn't matter.
> > There would be a second method, GetPartitionedSpaceAt(), with the
> > same
> > parameters which would return the space actually occupied by a
> > partition. The alternative to that is to add these information to
> > BPartition, which might indeed be the better approach. I thought of
> > keeping it out of BPartition to save 16 bytes (that aren't of
> > interest
> > for any other applications but DriveSetup), but considering that we
> > reserve 512 bytes for name and type of the partition, this wouldn't
> > really matter that much.
> >
> > The new methods to be introduce we be something like
> > UsableSpaceOffset() and UsableSpaceSize() (or nicer names :-).
> > Offset()
> > and Size() would then return the offset/size of the whole space
> > occupied by the partition.
>
> Again, I don't see why pulling that out of BPartition is a good idea.
Oh, I perhaps wasn't clear enough. UsableSpace{Offset,Size}() would of
course be BPartition methods.
I'll summarize all alternatives in the mail I'm going to write now. Er,
after lunch that is. :-)
CU, Ingo
Other related posts:
