[openbeosstorage] Re: Amiga RDB

On 2003-05-25 at 11:31:57 [-0700], Ingo Weinhold wrote:
> Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> >
> > 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.
> 
> I don't think using three virtual partitions instead of one make the
> whole thing better. What I see is, that partitions with and such
> without appear differently in the framework, even at different levels
> in the hierarchy (the usable space at least). A partition that 
> contains
> a FS and has reserved blocks is represented as one that contains
> subpartitions, which simply is a misrepresentation, that causes the
> problems described below.

Yes, I see what you mean. See below at the (nearly) very bottom for why 
I still feel this is acceptable. :-) 

> > 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.
> 
> In fact that is exactly not so. If the user could simply shrink a
> reserved partition, that would necessarily affect the adjoining non-
> reserved partition. Thus, a reserved partition would behave 
> differently
> from `normal' partitions, since usally resizing or moving a partition
> does not affect other partitions.

Yes, it would have different semantics. That's what the user gets for 
using partitions with reserved space, IMO. :-) On the other hand, 
there's nothing that says we have to support resizing of the reserved 
space partitions; we could certainly leave that out (considering the 
likelihood of encountering reserved space in real life, that seems like 
a worthwhile idea, actually :-) 

> Moreover, if one resizes the
> container partition (the one containing the three virtual
> subpartitions), the behavior is again different from resizing other
> partitions, since at least one of the contained virtual partitions
> (probably the non-reserved one) would need to be resized as well 
> (which
> as a side effect moves the second reserved partition).

Same stance as above. :-)

> The latter can also be applied on your first approach (to only have 
> the
> non-reserved space as virtual subpartition).
> 
> [...]
> > > 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().
> 
> 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.
> 
> > > 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.
> 
> As I see it, it would show a hierarchy where there is none. 

This doesn't really bother me, as it provides a clean way of showing 
where the reserved space is using the current framework. 

> And it
> would present partitions with and without reserved blocks differently
> (unless you intend to always have a virtual subpartition -- *shudder* 
> ;
> -).

No, I wouldn't do that; I'd save the virtual partitions only for the 
folks who plague us with reserved space. :-) 

> IMHO, the solution that most closely mirrors reality is to extend
> BPartition such that both occupied and usable space are represented, 

I am okay with this, too, although I like the virtual partition idea 
better simply because the exception to the rule is only dealt with when 
it's encountered, i.e. if we never see a partition with reserved space, 
no one will ever have to deal the the virtual partitions; adding the 
info to BPartitions means we and DriveSetup have to deal with it 
anytime we deal with partitions in general, regardless of whether or 
not reserved space is used. 

Also, the more partitioning systems we hit, the more odd cases like 
this we're going to encounter. If we continue to add special cases to 
BPartition for little things that are only encountered with a single  
partitioning system (and, in this case, not even necessarily in a 
frequent manner), we're going to end up with a much clunkier system 
overall. 

To support something like this, we have to take a hit in complexity 
somewhere. The virtual partition idea leaves the framework cleaner and 
purer, subjecting the user to a slightly fallacious view of reality in 
the odd case that they have reserved space in one of their Amiga 
partitions; the BPartition extension idea is more close to reality, but 
adds in two special case functions that will have to be accounted for 
everywhere partitions are dealt with, but will only actually have any 
relevance in a few cases.

Since resizing admittedly would be a little weird and probably more 
work than it's worth, we may as well just ignore that feature. That 
leaves us with the following two options:

(1) Use virtual partitions to handle the case of reserved space when 
it's encountered.  

(2) Add the following functions (I believe this is what you're 
intending, correct me if I'm wrong):

class BPartition {
        off_t UsableOffset() const;
        off_t UsableSize() const;
};

that normally would mimic Offset() and Size(), but for Amiga partitions 
with reserved space would give the non-reserved offset and size.

I still like (1) better, but am okay with (2) if you're still unsold on 
(1). :-) 

> or
> make these information available otherwise
> (BPartitioningInfo::GetPartitionedSpaceAt()).

No, I don't like not having the info somewhere in the partition 
hierarchy itself.

-Tyler

Other related posts: