[openbeosstorage] Re: DiskDevice API v2.1
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Tue, 08 Apr 2003 13:30:39 -0700
On 2003-04-08 at 12:01:21 [-0700], Ingo Weinhold 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.
Okay, that makes sense. Thanks.
> > > > > > > > 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.
Makes sense also. Thanks.
> > > 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.
Doesn't hurt compatibility w/ BFS.
> 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.
That could be handled gracefully (and contiguously) as well, though.
> > > > 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. :-)
Damn. :-)
-Tyler
Other related posts:
