Re: DiskDevice API v2.1

On 2003-04-05 at 08:00:25 [-0800], Axel D=F6rfler wrote:
>=20
> Tyler Dauwalder <tyler-cyCl/[email protected]> 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.
>=20
> 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).

We should all think very hard about it and maybe we'll come up with=20
something. ;-)=20

> > > > 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=3D3F Or is that too much overhead to get at the
> > necessary data=3D3F I guess that also wouldn't allowing booting a RAID
> > partition, but...
>=20
> 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.

Darn.

>=20
> > > > We could then also place the boot loader in that extra=20
> > > > 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=20
> > > block.
> > If we go with a metadata partition, I'd just as soon make it a
> > requirement from R1 on.
>=20
> 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=20
> 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=20
> loader,
> enabling things like RAID/resize/move for the boot partition as well

Oh okay. I was just wanting to get the transistion over with if it was=20
going to be all or nothing. :-)

>=20
> Without an extra partition, the boot partition could only be resized/
> moved off-line, as with Windows :-)

Actually, PartitionMagic allows online enlarging now of the boot=20
partition. :-)

> > > 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.
> > >=20
> > > 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.
> > :-)
>=20
> Thanks! I am looking forward to this.
>=20
> > Done. I hope I didn't miss anything. Yell at me if I did. :-)
> > http://www.dauwalder.net/DiskDeviceAPI=3D5Fv2.2.zip
>=20
> Thanks to you too :)

No problem. :)

>=20
> > > Either one could be returned, depending on whether the partition=20
> > > 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.
>=20
> With the option of setting the allowed size. Should be okay.

Good deal.

-Tyler