[openbeosstorage] Re: DiskDevice API v2.1
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Sat, 05 Apr 2003 17:40:00 +0200 CEST
Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> > > 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.
Yes, I have the same problems with it - especially because there are
only 4 primary partitions on the PC.
But the advantages it bring cannot be achieved otherwise (at least I
don't see a way).
> > > 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=3F Or is that too much overhead to get at the
> necessary data=3F I guess that also wouldn't allowing booting a RAID
> partition, but...
If that data would lie on the boot partition, you would not be able to
resize or move that partition as well. And yes, RAID wouldn't be
possible as well.
> > > 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.
No no! :-))
I don't plan to make it a requirement. And that's also because I don't
like having a spare partition for this as well.
The user can decide which way he wants to go, the system doesn't rely
on anything :)
If we don't do another file system for R2 (which could solve the
problems more nicely), we would have the following options for R2:
- leave it as is, the boot partition doesn't support any weird things,
the partition resize/move journal would be placed on the boot partition
as well, in a file.
- have a spare partition that contains the journal
- have a spare partition that contains the journal and the boot loader,
enabling things like RAID/resize/move for the boot partition as well
Without an extra partition, the boot partition could only be resized/
moved off-line, as with Windows :-)
> > 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=3D5Fscanner
> > module
> > (I would rename it to something like disk=3D5Fdevice=3D5Fmanager)
> disk=5Fdevice=5Fmanager works for me. :-)
For me too.
> > 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.
> :-)
Thanks! I am looking forward to this.
> Done. I hope I didn't miss anything. Yell at me if I did. :-)
> http://www.dauwalder.net/DiskDeviceAPI=5Fv2.2.zip
Thanks to you too :)
> > 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.
With the option of setting the allowed size. Should be okay.
Adios...
Axel.
Other related posts:
