Go to the FreeLists Home Page Home Signup Help Login
 



[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





[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.