[openbeosstorage] Re: Amiga RDB
- From: "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Tue, 27 May 2003 19:26:46 +0200 CEST
Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> On 2003-05-25 at 11:31:57 [-0700], Ingo Weinhold wrote:
>
> > > 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. :-)
:-)
OTOH, that brave guy is going to abandon his old OS in favor of OBOS
(argh, I was almost going to use the name that must not be mentioned
publicly 8-O) and a proper treatment. :-P ;-)
> 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 :-)
Carrying this argument a bit further, why should we add anything
special to deal with this strange case at all?
[...]
> > > > 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.
Aside from that I don't find this a clean way (let's name it: it's a
work-around and in the worst case it's going to confuse the user, since
it introduces different semantics), I don't even think that it allows
DriveSetup to display the reserved space in a helpful manner. Why? Just
let's think through, what amounts of reserved space we're certainly
talking about. Supposing that the reserved space is intended for system
data not belonging into the FS itself (not that could think of anything
useful), what quantities are we talking about? A few KB, maybe one MB?
DriveSetup will really have a tough time visualizing that at all,
considering common HS sizes (even my Amiga had a 540 MB HD (after I
replaced the 20 MB drive :-)). It should be hard enough to do that for
acual, small partitions like the apple partition map.
> > 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.
That wouldn't be too hard though. It's basically a question of which
methods, Offset()/Size() or UsableSpace{Offset,Size}() (in case those
were implemented), are to be used. For the normal API user it would the
second couple, for DriveSetup basically the first one.
> 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.
That's true.
> 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;
Others might consider it a ugly misrepresentation that adds confusion.
:-)
> 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.
Yep.
> 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.
Yes, that was an alternative I was thinking of. (Though, I named the
methods UsableSpace{Offset,Size}(), since UsableOffset() sounded a bit
odd :-).
> I still like (1) better, but am okay with (2) if you're still unsold
> on
> (1). :-)
Give me the chance to list a hopefully complete list of options belows.
> > or
> > make these information available otherwise
> > (BPartitioningInfo::GetPartitionedSpaceAt()).
>
> No, I don't like not having the info somewhere in the partition
> hierarchy itself.
One could argue, that this way would cleanly separate two different
views on the partitions: The user view (only usable space is of
interest, not the actual occupation of disk space) and the disk usage/
partitioning view (DriveSetup would take). That's why I considering
putting both the partition disk usage and the partitionable space info
into the BPartitioningInfo class.
Let me list all alternatives with a bit of comment:
1) Ignore the reserved space issue. BPartitions would present the
usable space only, and DriveSetup might visualize the disk usage not
exactly accurate. This is merely hypothetical for a) probably noone
uses reserved space and b) if, as I expect, the reserved space is
relatively small, then we wouldn't be able to represent it graphically
anyway. A textual representation is there in any case, since the GUI
add-on for the Amiga RDB scheme would display (and perhaps allow to
edit) it.
2) Virtual partitions. The framework itself would not need to change
either. The representation of a concerned partition would differ from
the representation of `normal' partitions, which would lead to
different semantics of resizing the partition, if enabled. Resizing of
the reserved spaces would lead to problems as well (especially the
transition from no reserved space to reserved space and vice versa) and
would probably need to be disabled as well.
3) Explicit representation of the reserved spaces or rather the
occupied vs. the uable space.
a) Addition of members to BPartition (UsableSpace{Offset/Size}()).
b) External represention of the info (BPartitioningInfo).
In general this is an API extension for a virtually unused feature (at
least Amiga RDB is the only scheme known to me that provides it (I just
checked EFI, which doesn't either); if reserved space is actually used
in practice, Axel will hopefully tell us one day ;-). So, scepticism is
appropriate. The difference between a) and b) is basically object- vs.
view-orientation.
Now, balancing the arguments I tend to like 1) most. I would perhaps
revise this judgement, if Axel told us, that the reserved space stuff
is indeed used in practice and the size of the reserved space is
usually rather large (like dozens of MBs, which I strongly doubt). Then
I would favor 3), for I really don't like 2). Sorry Tyler, I can't get
to like the virtual partitions.
CU, Ingo
Other related posts:
