FreeLists / openbeosstorage / [openbeosstorage] Re: Amiga RDB

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

On Tue, 10 Jun 2003 02:50:04 +0200 CEST "Axel Dörfler" <axeld@pinc-
software.de> wrote:
> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > I am not yet sure how to handle the real partition size - I'll 
> > > have 
> > > a 
> > > deeper look at Amiga FFS though, and then I might know. Right 
> > > now, 
> > > I 
> > > would think that it's best to simply let the file system decide 
> > > what to
> > > do with this extra space; at least it looks like the contents 
> > > differ on
> > > different file systems - that means, that the partition would 
> > > span 
> > > the
> > > whole space including the reserved areas.
> > > It would just be nice if the file system could access the space 
> > > information, though.
> > Mmh, we have rather few options: We publish a device for the 
> > partition 
> > that either includes the reserved space or that doesn't. Unless I 
> > miss 
> > something, Linux has exactly the same options for its /dev/hdaN. If 
> > your observation is correct, then those partitions include the 
> > reserved 
> > part. I find this not nice, because that means, the file systems 
> > must 
> > be aware of the underlying partitioning system. Not that this was a 
> > problem for us...
> 
> It could also just assume always 2 blocks and ignore that number 
> completely. That is, the AmigaFFS handler would not use those 2 
> blocks 
> for anything else, but all other file systems would.
> BTW the "disk_environment" structure which contains the reserved 
> blocks 
> information also contains the block size used for the file system - 
> so 
> the file system should have access to that information in anyway.
> How do we want to do this? The easiest way would be to reserve some 
> keywords for the driver_settings structure. That is, the file system 
> gets something like "block_size = 512; reserved_blocks_at_start = 2;" 
> added to the standard parameter string. Of course, that is dangerous 
> information, but does anybody has a better idea?
> We could even have a prefix for them that is filtered out when coming 
> from userland (like "_system_").

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.

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.

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.

CU, Ingo