
|
[openbeosstorage]
||
[Date Prev]
[04-2003 Date Index]
[Date Next]
||
[Thread Prev]
[04-2003 Thread Index]
[Thread Next]
[openbeosstorage] Re: DiskDevice API v2.1
- From: Tyler Dauwalder <tyler@xxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Wed, 09 Apr 2003 00:06:38 -0700
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?
> > 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
|

|