FreeLists / openbeosstorage / [openbeosstorage] Re: Amiga RDB

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

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.

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

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. And it 
would present partitions with and without reserved blocks differently 
(unless you intend to always have a virtual subpartition -- *shudder* ;
-). IMHO, the solution that most closely mirrors reality is to extend 
BPartition such that both occupied and usable space are represented, or 
make these information available otherwise 
(BPartitioningInfo::GetPartitionedSpaceAt()).

CU, Ingo