[openbeosstorage] Re: DiskDevice API v2.1

Tyler Dauwalder <tyler@xxxxxxxxxxxxx> wrote:
> On 2003-04-08 at 23:23:22 [-0700], Axel Dörfler wrote:
> > "Ingo Weinhold" <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > > > 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.
> > > Ah, right.
> > 
> > As long as you don't run chkbfs, there wouldn't be a problem with
> > compatibility to BFS, since you could just mark that area as used 
> > in
> > the block bitmap and any BFS will honour that without caring about
> > what's actually using it.
> 
> 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.

> > > Sounds more complicated though. In particular because the 
> > > interaction
> > > between the system (kernel, disk device manager -- whoever is
> > > responsible for partitioning) and the FS will be more complex, 
> > > since
> > > the FS would move the log file, which itself is a transaction 
> > > that
> > > needs to be logged, and while the system is responsible for 
> > > logging.
> > > I
> > > guess, we need to work on the details before being able to do 
> > > further
> > > evaluation. It may be worthwhile to pursue, though.
> > 
> > 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?

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

> So are you ruling out having a special, easy to find, always 
> contiguous 
> chunk of data within the BFS volume (either at an known position, or 
> referenced from the superblock, I suppose) being used for the 
> DiskDevice log, or just a special, but otherwise  "real" file? Or is 
> your splitting argument due to wanting to support RAID layout info 
> within the same data chunk as the DiskDevice log?

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.
(Re-reading the paragraph, I'm not really sure, what I wanted to say, 
but I remember, that I had a moment of clarity when writing it, so I 
believe, it must make sense and somehow answers you last question. ;-)

CU, Ingo

Other related posts: