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

["Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx>]

Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> On 2003-04-05 at 08:00:25 [-0800], Axel D=3DF6rfler wrote:
> >=3D20
> > 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.
> >=3D20
> > 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=3D
> 20
> something. ;-)=3D20

We could simply use disk space not assigned to any partition, but I 
don't think, that's a good idea. Furthermore, there is the possibility 
to use a logical partition instead of a primary one. This might 
restrict the options a bit, but at least no primary partition is 
wasted.

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

Well, for software RAID you'll never get a around using a partition on 
a non-RAID disk (unless the BIOS supports it ;-).

To store the data on the boot partition is an option, I think. I 
wouldn't use a file, but leave some room for the meta data at the 
beginning. ReiserFS for instance skips the first 64 KB. That would be 
space enough for quite a bunch of RAID settings and a small job 
journal. But even 1 MB or so wouldn't hurt. Perfect would be to make 
this an option when initializing the volume. Be's BFS add-on wouldn't 
be able to read such a volume, but I think, that doesn't matter much.

What's the benefit=3F I believe, then resizing and moving the boot 
partition is possible, too. Resizing should be no problem at all, 
moving is a bit more difficult, but managable, I think.

> >=3D20
> > 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=3D20
> partition. :-)

Journalled=3F Could you please try and turn off power while resizing. ;-
))

> > > > 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.
> > > >=3D20
> > > > 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.
> > > :-)

Damn, I should have waited till you propose to do it. ;-)
Anyway, I'm afraid, I won't be able to finish it today. Especially not, 
if this email `battle' continues. ;-)

CU, Ingo