FreeLists / openbeosstorage / [openbeosstorage] Re: Amiga RDB

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> On 2003-05-27 at 11:54:17 [-0700], Ingo Weinhold wrote:
[...]
> > 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. :-)

Sure, a minimal size should be used. I was just thinking of how it 
would look like, if you have several partitions, each with reserved 
space at the beginning and the end. DriveSetup would present you a 
pretty distorted view of your HD. :-)

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

Life is cruel. ;-)

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

That certainly won't be held against you. ;-)

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

OK, it seems we could all live rather well with 1) (unless Axel vetos). 
So, let's go for it.

CU, Ingo