FreeLists / openbeosstorage / [openbeosstorage] Re: Amiga RDB

[Tyler Dauwalder <tyler@xxxxxxxxxxxxx>]

On 2003-06-10 at 17:10:24 [-0700], Axel Dörfler wrote:
> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > On Tue, 10 Jun 2003 02:50:04 +0200 CEST "Axel Dörfler" <axeld@pinc-
> > software.de> wrote:
> > > "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > The block size is no problem, for we have a block_size field in the
> > partition_data structure. The partitioning system fills it in and 
> > the
> > file system can read it. All other partitioning systems simply fill
> > in
> > the block size of the parent partition, while all file systems
> > specifying their block size in their super block will overwrite it.
> 
> Actually, partitions can have another block size, at least from the
> RDB's POV - it defines the block size of the disk, whereas the
> disk_environment structure defines it for the file system itself.

Correct me if I'm not following along here, but say you have a disk 
with an Amiga RDB that has a single Amiga FFS partition. Wouldn't the 
BDiskDevice partition get the RBD's block size, and the single child 
BPartition get the disk_environment size?

> > That leaves us with the reserved blocks. There's still the option to
> > add respective fields to the partition_data structure. That doesn't
> > necessarily mean, that we have to make that info available to the
> > userland API. I don't really like the idea to let a disk system
> > interpret the private parameters of another one.
> 
> Definitely.
> 
> > I'm not even sure, that I want to enforce to use the driver settings
> > format for the parameters. Most modules will certainly want to use
> > it,
> > since it saves them the parsing/unparsing task, but I wouldn't rule
> > out, that there might be a disk system, which has it's parameters
> > already in a handy string form (in case it's just a name or 
> > something
> > like this) and would unnecessarily need to convert it.

But if it's something simple like that, converting it into 
driver_settings format won't be too taxing either. 

> For file systems, I want to enforce the driver_settings format. I 
> don't
> know if it makes sense to loosen that limit for the partition modules,
> but if you could come up with a good reason :-)
> And that information would only be of interest for file systems, so we
> could just add it there. But we'll see - I still have to extend the
> current driver_settings implementation for this usage.
> 
> There is also another "Huston, we've got a problem": our support for
> nested partitions - imagine an Intel or Apple style partitioned disk
> where the first partition starts within the first 16 blocks - which is
> very much possible.
> If this partition contains an AmigaRDB style partitioned "subdisk",
> we'll get into troubles, since the Amiga RDB could think it would be
> the only partition system on the disk if it's asked first. Have you
> guys any idea about this?
> The only one I would have is:
> a) give it a lower priority, so that it alsways comes last to identify
> a partition
> b) lower the amount valid locations for the block - that would be
> against the standard definition, but seem to be compatible with common
> usage

a) seems like it would be sufficient to me.

-Tyler