FreeLists / openbeosstorage / [openbeosstorage] Re: Amiga RDB

[Tyler Dauwalder <tyler@xxxxxxxxxxxxx>]

On 2003-05-27 at 11:54:17 [-0700], Ingo Weinhold wrote:
> 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 ;-)

That's a reasonable point, I suppose. :-)

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

To make what's-his-name, the brave guy, happy, I thought. :-P ;-)

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

Well, I think we'll need to set a minimum partition display size anyway 
if we're going to make a graphical DriveSetup display also work as a 
functional user interface element (or maybe you're not intending that? 
It's not exactly critical, but I think it'd be nice). Partition Magic 
does this, and it seems to work just fine to me, even though it then 
doesn't always display a perfectly accurate view of the world. Like you 
said, if it did display things accurately, we'll end up with very small 
partitions on large hard drives being one pixel wide. :-)

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

I can't fathom who... :-)

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

Either naming is fine with me.

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

Here is part of the source of my objection to the separation, then. 
I've just assumed anyone using the API for whatever reason would be 
interested in the whole picture, and if there are parts they wish to 
ignore, then they can do so, without us separating everything for them 
ahead of time. Though I do see where there could be an advantage to 
slimming down the user-intended interface to the more applicable set of 
operations... I think I still prefer have everything in one place (even 
from a user perspective). 

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

This is sounding better and better all the time. :-)

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

I fear the virtual partitions idea will share the same fate as 
BPartitionableSpace very soon... :-)

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

FWIW, I prefer the object orientation in this case.

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

Yes, I think I currently like 1) best as well. Otherwise, I can just as 
easily handle 2) or 3), and since 2) has not gone over very well at 
all, I would go for 3) as well. :-)

-Tyler