FreeLists / openbeosstorage / [openbeosstorage] Re: Amiga RDB

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On Wed, 11 Jun 2003, Tyler Dauwalder wrote:

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

I can only second that question. There seems to be no problem in my eyes.

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

OK, you have a point here. :-)

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

Since I will need it rather soon -- basically only the disk system
management in KDiskDeviceManager and the basic C functions exported by the
disk manager are to be done, before I will start to port the intel module
to the new interface -- I can do that, if you don't object.

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

Yes, it seems to make some sense to give a system with laxer constraints a
lower priority.

CU, Ingo