Re: DiskDevice API v2.1

On 2003-04-08 at 23:23:22 [-0700], Axel Dörfler wrote:
> "Ingo Weinhold" <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> 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?

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

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?

-Tyler