[openbeosstorage] Logging/RAID
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Thu, 10 Apr 2003 00:00:42 -0700
> > 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).
>
> That's a good idea! And no, I don't think it would be similar to a
> spare partition, since that space is only needed temporarily while the
> partitioning jobs are being performed.
>
> So, how about the following procedure:
>
[SNIP]
Now that I like quite a bit. :-) I especially like not needing to
dedicate a separate (true) partiton to the deal.
> If the boot partition is not affected by the changes, the whole
> process
> can be simplified by logging to a file on the boot partition. For 2.
> there are some more options. E.g. resizing a partition doesn't need
> external logging, if the FS is journalled anyway.
That last part I'm not so sure about. I for some reason imagined we
would be doing complete logging (i.e. meta data AND user data). If not,
then fine, the last sentence is still applicable. Although, now that I
think about it, I guess you *could* enable loggind of data being moved
during repartitioning ops within the filesystem itself. In fact, that
seems like it might even be necessary, for otherwise how could someone
with a single BFS partition spanning their whole device have journaled
resizing?
> And if more than one
> partition shall be changed, the changes can be done consecutively, so
> that the log can be relocated for each job.
Yes.
> It may be a bit of a challenge to generalize such a process to work
> with arbitrary partitioning systems.
Yes. It would probably behoove us to read up on other partitioning
systems and how they interact with the boot process. Unless either of
you are well versed in that already. :-)
So, I would like to regroup here, if you don't mind, as I keep feeling
either slightly lost, or like points are being made about differeing
problems/systems (though it could be just me :-). We have the following
needs, correct?:
1. Somewhere to write information about currently processing
BDiskDeviceJobs to allow the system to start up said jobs again if
interrupted. How about calling this the job log for ease of reference?
2. Somewhere to store any code needed to reinitiate and finish
interrupted BDiskDeviceJobs, i.e. the job completion code.
3. To have the main (i.e. boot) partition be a RAID partition, a
special partition containing enough info and code to get the RAID
subsystem going must be available. All remaining RAID configuration can
be stored on the boot partition (whether that partition is a RAID or
not).
Have I missed anything or gotten anything wrong?
Assuming not (or thereabouts :-): To my mind, 1 and 2 need have nothing
to do with 3 if no boot RAID partition is involved, and something along
the line of Ingo's proposal above would probably work nicely. If a boot
RAID partition *is* part of the changes, the data for 1 and 2 could be
placed somewhere in the necessary partition for 3, and all is well
again.
There also could be a need for:
4. A place to log filesystem changes during repartitioning ops.
But I really like the idea of leaving that problem to the fs itself.
So, thoughts, corrections?
-Tyler
Other related posts:
