[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).
Hi,
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!
Janito
_________________________________________________________________
Hotmail: Free, trusted and rich email service.
https://signup.live.com/signup.aspx?id=60969
Other related posts:
