FreeLists / openbeosstorage / [openbeosstorage] Re: DiskDevice API v2.1

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

"Axel D=F6rfler"  <axeld@xxxxxxxxxxxxxxxx> wrote:
> 
> "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > The main motivation is that it gives the partition code a chance 
> > > to 
> > > declare what regions of unused space are valid for creating child 
> > > partitions. 
> > This might indeed be a good idea. Since the systems have some 
> > administrative overhead (the PTSs in the intel system), it could be 
> > quite convenient.
> 
> We will also need some kind of overhead or better a spare partition 
> for 
> the partition meta data in R2. That includes things like how the 
> partitions have to be mapped during a move operation, but also 
> informations about the RAID setup or similar things.

I like that idea.

> It probably won't be possible to write this information down to an 
> existing file system.

Right.

> We could then also place the boot loader in that extra partition, so 
> that the boot partition is free of any file system requirements (and 
> could itself be located on a RAID partition) :-)

Wouldn't that be a good idea even for R1. I mean, then there wouldn't 
be the need to squeeze rudimentary BFS support into the boot block.

[...]
> > > Why do you prefer the userland version=3D3D3F
> > I reconsidered that, and I'm about to change my mind. :-)
> > The reason, why I tended to like the userland version more, was 
> > that 
> > it 
> > is more lightweight -- a simple virtual function called vs. a 
> > syscall. 
> > But the API is not exactly performance critical and, I would be 
> > surprised, if thousand or more invocations per second would have 
> > any 
> > significant impact on modern hardware. So, even live checking of 
> > partition positions, while the user drags a slider or something 
> > like 
> > that, should be no problem at all.
> > 
> > The big plus on the kernel version's side, is that using a 
> > partition's 
> > BDiskSystem doesn't require the respective userland add-on to be 
> > loaded. Only the kernel module, which needs to be loaded all the 
> > time 
> > anyway.
> 
> But keep in mind that in R1, kernel memory might not be pageable. So 
> a 
> userland add-on could be thrown out of memory while a kernel add-on 
> might not.

Yes, but there will be relatively few actually used partitioning 
systems -- for x86 machines the intel one and the session support for 
CDs -- and they are not exactly huge either.

> But I hope we'll get that right for R1 already.

That would be cool.

> Could you make a list of what kind of functionality the kernel module 
> should contain and how it should be accessed from userland=3D3F

Roughly, for the partition modules, it should be more or less the same 
as it is now, plus a function per BDiskSystem method (or one function 
for all of them). Userland access via syscall. The disk=5Fscanner module 
(I would rename it to something like disk=5Fdevice=5Fmanager) would need to 
be extended vastly. It would incorporate the functionality currently 
implemented in the registrar, plus support for locking, managing jobs 
and the like.

I'd like to write up a design draft for that part, so that we have 
something more concrete to discuss about. Tyler, could you please 
update the 2.0 API according to the changes discussed over the past 
days. That should make it a bit easier for me to work with it. If you 
don't have time, just give a yell; the old one together with the mails 
will do then.

[...]
> > > Sounds good, though should ValidateInitialize include an off=3D
> > > 3D5Ft *
> > > size 
> > > as 
> > > well=3D3D3F
> > To return the size the system would actually use, so that the 
> > caller 
> > is 
> > e.g. able to warn the user, if space would be wasted when trying to 
> > initialize the partition with a FS with a smaller maximal size=3D3D3F
> 
> Dunno if that's necessary.
> It would make more sense to set the minimum size the file system 
> supports there (if the provided size is smaller) :-)

Either one could be returned, depending on whether the partition is too 
small or too large. But let's listen to what Tyler originally intended 
it for. :-)

CU, Ingo