[haiku-development] Re: ext3 Journal Design Considerations

  • From: Janito Ferreira Filho <jvffprog@xxxxxxxxxxx>
  • To: Haiku Development <haiku-development@xxxxxxxxxxxxx>
  • Date: Wed, 14 Apr 2010 12:49:58 +0000

> axeld@xxxxxxxxxxxxxxxx:
> Of course you would want to find a common base class for this; how that
> looks exactly is something I can't really understand from your
> suggestion - at least there shouldn't be any mapping involved with
> external logs, only redirecting the request (the journal class shouldn't
> need to know the on disk location in the log, only it's position in it).


currently, the base class is just the Journal class. It does everything the 
journal has to do, except handling block mapping. Block mapping is direct in 
the base class (meaning that, if we have different devices for the the journal 
and the file system, it will probably work correctly, or at least require 
little change). However for a normal journal and file system on the same 
device, we have to map the journal blocks to disk blocks through the journal 
inode. That's the purpose of the virtual MapBlock method, and it also allows 
that only the (temporarily named) "InodeJournal" class needs to know about 
Inodes, at least in theory =).

> Possibly, I don't know yet :-)
> I can't really see much use in a block cache in the journal; the journal
> has nothing to do with the block cache - it doesn't cache things, it
> only knows where to store (and restore) stuff.

I think that currently the block cache is only useful in the journal for 
recovery (because of multiple passes). And using a "Volume" object (with 
support for CachedBlock) would provide a common interface for the device, being 
it for the file system, the journal or both. However, I think it's possible to 
make a different interface (perhaps using only file descriptors, or possibly 
having a virtual ReadBlock method). I think this will only get a final solution 
when transactions are supported, because then we can see how we are going to 
use the blocks inside a transaction. For now, I think I'll keep it this way 
because it's simple and will allow easy support for the "InodeJournal" class. 
When (or if...) external journals are really supported, this can be changed.

> The latter is always the preferred option. Usually, it makes sense to
> think about the requirements first, and then choose an algorithm that
> meets them -- as long as you reuse existing functionality, there is no
> overhead to implement the right solution from the start.

Again using inheritance, I'm creating an abstract class called RevokeManager, 
and allow subclasses to implement different managing schemes. I think it will 
be easy to do a HashRevokeManager using the kernel hash functions, but I need 
to study it a little more.
> You design the software you write, so you are completely responsible.
> However, it's the responsibility of your future mentor to make sure you
> are on the right path :-)
> IOW you should think of a good and fitting design, and your mentor would
> then try to criticize or approve it.

Okay =). For now can I keep posting here? Thanks for your reply!


Hotmail: Free, trusted and rich email service.

Other related posts: