[openbeosstorage] Re: DiskDevice API v2.1

Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> On 2003-04-05 at 12:05:33 [-0800], Ingo Weinhold wrote:
[...]
> > 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.
> 
> Yes. BTW, what is the difficulty in booting from a logical partition?

If I understand Axel correctly, there's none for the stage one boot 
loader -- I suspect, because it uses the BIOS. And the stage two 
bootloader simply needs to have a rudimentary understanding of the 
intel partitioning system built in -- probably a stripped down version 
of what we are coding.

> > > > > > > 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 ;-).
> 
> Why is that (I know next to zero about RAID :-)?

I wouldn't say, I know that much about RAID. I'm more or less doing 
educated guessing here. Hardware RAID should be no problem at all, 
since the RAID controller makes the array appear as a single disk to 
the system. RAID 1 (simple redundancy) might also boot without problems 
when implemented in software -- it would just boot from one disk. The 
other RAID versions (0, 10, 4, 5) distribute the data over the disks, 
so that the BIOS -- unless it supports RAID -- probably won't even find 
the boot loader or at least wouldn't be able to locate the partitions 
correctly.

> > 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.
> 
> That seems like a good idea. Though why not in a file: the access 
> overhead, or contiguity, or...? If it were a setting at initialize 
> time, you could certainly guarantee a contiguous chunk.

Firstly, I wouldn't see the benefit of a file, if you have to create it 
at initialize time and can't change its size later on. Secondly, there 
is a good chance, that you have to move that file, when you're resizing 
the partition. If you place it at the beginning of the data space, you 
might have to move it, when the partition is enlarged (the bitmap will 
grow). And otherwise you might have to move it, when the partition is 
shrunk.

> > > Actually, PartitionMagic allows online enlarging now of the 
> > > boot=3D20
> > > partition. :-)
> > 
> > Journalled=3F Could you please try and turn off power while 
> > resizing. 
> > ;-
> > ))
> 
> Oh, I don't have that newest version, I'm afraid. :-P If anyone is 
> interested in ponying up the $70 US or whatever it costs, I might be 
> willing to see. :-)

Never mind. :-)

[...]

CU, Ingo

Other related posts: