[openbeosstorage] Re: Amiga RDB

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

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

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

What do you think?

Adios...
   Axel.

Other related posts: