[openbeosstorage] Re: DiskDevice API v2.1
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Wed, 09 Apr 2003 22:58:24 +0200 CEST
"Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > I thought the compatibility argument came from suggesting to shift
> > the superblock forward to make room for the log, though. Wouldn't
> > that confuse BFS?
> I thought of putting the log between the superblock and the bitmap,
> so
> that it wouldn't need to be moved, when the partition is resized. I
> don't know, how BFS locates the bitmap (an entry in the superblock or
> a
> fixed position?) -- perhaps that would even be possible without
> breaking compatibility.
Sure, it would be possible. Only the bitmap has a fixed location on
disk - it starts at block numer 1 (so the exact position depends on the
block size used in BFS).
The position of the log is written down in the super block. You could
even change the size afterwards, if you wanted to (note, I haven't
checked that the original BFS would work with a different log size, but
I would be very suprised if it didn't).
> > > I'd say it's almost impossible to do with the way we are booting.
> > > We currently have almost 800 bytes to load the 2nd stage boot
> > > loader from a BFS disk. Now add locating (any chunks) and parsing
> > > of that log file to it, and you'll undoubtely would need about 16
> > > kB more :)
> Firstly, I wouldn't not allow that at any time there isn't a non-
> contiguous log (or if I would, it would need to be *very* easy to
> reconstruct the complete one (e.g. the first part could contain a
> pointer to where the second part starts)). Secondly, we have that 16
> KB
> of code, if we like. Who says, that the meta data space could only
> contain logging data? We can put as many code into it as we want to.
> I
> even think, we have to put code into it, since where else would the
> code replaying the log come from, if the system went down while
> resizing the boot partition?
That's right, I would have placed code like that into the spare
partition, so that would also go into that area when it's directly on
the moved partition.
> > > And worst case could be that these 800 bytes are also split in
> > > half
> > > which would be really impossible to fix.
> > Sorry, you kinda lost me here.
> I'd understand it like the system died while moving the partition,
> and
> only the first block of it has already been moved. I believe, this
> can
> be prevented, though.
Not really. The hard disk kinda guarantees (or at least everybody
assumes) that reading/writing one block is an atomic operation.
Now, the boot block is always the block that the BIOS will jump to.
Updating the partition block entry to the new location is not a good
idea, because other operating systems shouldn't boot without being
aware that everything is currently nuts. But of course, that's always
not a good idea.
A (non-movable) spare partition would make sure that OpenBeOS will be
booted as long as the partition change is not completed (because it can
replace the MBR with a version that will load it).
Although, now that I wrote it, a similar solution might also be
possible with an area on the moved partition. But it would require an
untouched area on the disk that can be used while the job is being
performed (which would be very similar to a spare partition).
> I still believe, you can't have a software RAID setup on the boot
> partition, if the BIOS doesn't support it. So, if the RAID layout
> info
> was in that chunk, which itself is located on the boot partition, the
> boot partition can't live on a RAID disk, anyway.
Also don't forget that the file system doesn't know about RAID. It's
the level below the file system that achieves RAID.
You need to have a certain block of data on a hard drive in the
software RAID that boots the system and know about the RAID structure.
Adios...
Axel.
Other related posts:
