[haiku-gsoc] Re: Block Cache and Transactions
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Thu, 01 Jul 2010 08:42:48 +0200
Janito Ferreira Filho <jvffprog@xxxxxxxxxxx> wrote:
> can someone help me with understanding correctly the block cache?
> If I understood it correctly, BFS uses sub-transactions as a way to
> chain
> together different transactions. Is this true?
Exactly. Since you have to sync the disk caches after each transaction
in order to be sure it has been written back to disk, the block cache
allows you to use sub transactions. Once such a sub transaction is
completed, it is merged with its parent transaction - but until that
merge happened, it can be decoupled again, too.
> Another thing is about transaction locking (happening in the BFS
> Journal
> code). The idea is to guarantee transaction ordering by allowing only
> one
> transaction to be active at a time, or rather, allow only one thread
> of
> execution to work with transactions at a time and having it guarantee
> it
> orders the transactions correctly?
Yes, BFS only supports a single log, and everything you write to it has
to be serialized.
> Is this correct? Any remarks I should be aware of about how
> journalling
> should be implemented? Thank you,
Just keep in mind that open transactions are kept in memory completely.
And not only that, also the unchanged blocks are preserved in memory,
so that you can easily revert an open transaction (this could be
improved, though, and read back from disk if memory becomes tight).
Anothing thing you have to be aware of is that, since the file cache
and block cache are separate, they could also struggle for the same
block on the disk. That's why you may have to use the
block_cache_discard() function if you plan to use disk blocks for the
file cache that were previously used by the block cache (it tells the
latter not to clobber them anymore).
Bye,
Axel.
Other related posts:
