[openbeosstorage] Re: DiskDevice API v2.1
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sat, 05 Apr 2003 00:08:46 -0800
On 2003-04-04 at 10:28:34 [-0800], Ingo Weinhold wrote:
>
> "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.
Initially, I'd say I don't like the idea. However, I mostly just don't
like the messiness of having an extra partition floating around. For
example, I hate having to make separate linux swap partitions. But
that's just a personal dislike. That being said, I recognize the
advantages it could bring.
> > It probably won't be possible to write this information down to an
> > existing file system.
>
> Right.
My one question is, couldn't a special file referenced from the BFS
superblock be used? Or is that too much overhead to get at the
necessary data? I guess that also wouldn't allowing booting a RAID
partition, but...
> > 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.
If we go with a metadata partition, I'd just as soon make it a
requirement from R1 on.
> > 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)
disk_device_manager works for me. :-)
> 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.
Great! I was about to bring that up, but now I can sit back and relax.
:-)
> 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.
Done. I hope I didn't miss anything. Yell at me if I did. :-)
http://www.dauwalder.net/DiskDeviceAPI_v2.2.zip
> [...]
> > > > 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. :-)
I intended it for general size bounds checking. So too small, too big,
etc.
-Tyler
Other related posts:
