FreeLists / openbeosstorage / [openbeosstorage] Re: Amiga RDB

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> 
> On 2003-05-23 at 09:42:49 [-0700], Ingo Weinhold wrote:
> > "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
> > > "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > [...]
> > > > > Anyway, for now, I don't think we have to deal with it - just
> > > > > report
> > > > > the accessible partition size and we're happy.
> > > > I would actually rather like to do it right in the first place,
> > > > i.e.
> > > > let's either decide in favor one way or another, but not for
> > > > preliminaries.
> > > > 
> > > > The question that comes to my mind is, what function has this
> > > > reserved
> > > > space sticked to a partition? I can't really think of anything 
> > > > that
> > > > makes much sense. And if that's the case, then I'm tending to 
> > > > favor
> > > > dealing with it in the stepmotherly way outlined earlier, 
> > > > instead
> > > > of
> > > > extending the API just to include a nice handling for that
> > > > particular
> > > > partitioning scheme.
> > > 
> > > I don't even know if it is used by any file system, so maybe we
> > > should
> > > even think about wanting to support it :-)
> > > But I could at least check if any of my collection of hard disks 
> > > do
> > > that :-)
> > 
> > That would be great! When moving last year, I disposed a lot of 
> > things
> > I had no longer need for. Among those also all my Amiga stuff (not
> > light-heartedly though). So, I can't check it myself.
> 
> Is Amiga still used in Germany?

Yep, Germany is so backwards, most people are still using C64s and 
Amigas. ;-))

I believe, Amigas are at least mostly disappeared from business. Though 
three years or so ago, when Stippi and I started with eXposer, Take2 
(on Amiga) was still a very popular line testing program. But I think, 
aside from those obscure applications only hardcore fans still use the 
Amiga. Mostly gathered around the companies producing (or promising) 
Amiga successor products. Nevertheless, according to what can be read 
on OSNews from time to time, the community seems to be much greater 
than the BeOS community.

> I know mphipps was an Amiga fan, but 
> Amiga was really nothing more than a legend to me until I started 
> working on this project. I've never even so much as seen an Amiga 
> box...

Ooohh! 8-O

> > > > I'm a bit uncertain, whether I start to dislike the
> > > > BPartitionableSpace
> > > > objects. In the case of this partitioning system they would
> > > > certainly
> > > > respect the reserved space attached to the partitions and thus 
> > > > make
> > > > DriveSetup think, that the partitions can't be moved only a 
> > > > short
> > > > distance, as that would invade non-partitionable space.
> > > 
> > > That reserved space would have to belong to the partition itself, 
> > > I
> > > think. But if you start to dislike the BPartitionableSpace 
> > > objects, 
> > > I
> > > can't stop you ;-)
> > 
> > Hehe. I'm still waiting for a plea from Tyler to keep them. :-P
> 
> If anyone has a better idea, I'm willing to hear it out. :-P :-)
>
> Why not make the non-reserved space a virtual sub-partition of the 
> actual partition? Then you could still move the entire partition 
> around, reserved space and all, while respecting the reservations.

That would be a solution only, if the partition in question 
accommodates subpartitions, what, according to Axel, the RDB doesn't 
natively support (we would provide nesting of partitioning systems 
though). In case of a file system to me it doesn't seem to work very 
well, for we would then have both, subpartitions and a file system. We 
couldn't simply publish the whole partition as a device.

A similar problem occurs when we explicitly support reserved blocks at 
the beginning and end of a partition in the API. Although then we can 
at least be sure that there won't be a reserved subpartition in the 
middle of a partition. The ugliness with the publishing of the device 
could be solved by having the reserved space live before/after and not 
at the beginning/end of the partition. But then the handling of child 
partitions becomes less nice.

But rather than wasting another 16 bytes per partition, I'd like to 
ignore those reserved blocks in the API and hope that this feature is 
virtually unused. The partition module would take care, that no bad 
things happen in cases where it is used, and DriveSetup would visualize 
such a setting slightly suboptimal. Well, and BPartitionableSpaces 
would suck...

Maybe it's a good idea to remove them from the BPartition anyway. Mind 
you, resizing/moving a partition will also always affect sibling 
partitionable spaces (up to four in case of moving), which might be a 
bit hairy to handle. Since the information the BPartitionableSpaces 
provide are of interest only, if one is going to modify the partition 
layout (and would only waste resources otherwise), it might make more 
sense to retrieve them on request only. E.g. via a method 
BPartition::GetPartitionableSpaces(BObjectList<BPartitionableSpace> *
spaces). Or maybe even more consequent: 
BPartition::GetPartitioningInfo(BPartitioningInfo *info), where 
BPartioningInfo could not only know, which are the free spaces, but 
also which space is assigned to which subpartition. This would also 
solve the problem with the RDB's reserved space at the beginning/end of 
partitions, since the BPartitioningInfo would consider the complete 
space occupied by a subpartition.

CU, Ingo