[openbeosstorage] Re: DiskDevice API v2.1

"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> 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.

Yes, support for booting from logical partitions would have to be in 
the 2nd stage boot loader, and in our writembr/bootmanager tools.
The BIOS will just load the first 512 bytes from the boot disk, and 
then executes it. That code (ours) would then have to jump to the 
logical partition instead of the primary one - that would be very easy 
and doesn't really require that much.
Hm, even the 2nd stage boot loader could locate and load the kernel 
without the need for support for logical partitions, as long as it 
would get an offset (and size) to the partition it's on.

> > 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.

That's pretty much it. How are you supposed to locate the boot loader 
or the kernel when you don't know what makes up the volume?

> > 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.

A file wouldn't work - for example, in case of a sudden system death, 
you would still need to be able to load that data. And a file or any 
data on that partition might have been cut in half at that moment.
You wouldn't be able to load the boot loader, nor to extract the data 
about how the partition structure currently looks.

Adios...
   Axel.

Other related posts: