On 04/14/2010 04:36 AM, Janito Ferreira Filho wrote: > I have a couple of questions regarding how to create a proper journal > implementation. The first thing I'm not sure about is class inheritance. > Is there anything in Haiku that recommends against it? Because I > currently have a plan to use it for two things. The first would be for > the Journal. I made a virtual function (MapBlock) that on the normal > Journal class just return's it's argument. The idea is to allow the > creation of an JournalInInode class (or something like that) that maps > the block correctly to a file inside the volume. This way, I think I'm > future-proofing for journals outside of the file system device. Do you > think this is elegant, or just bloat? 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). > The second use would also be for future-proofing for external journals. > The idea is to "rename" the Volume class into "Ext3Volume", and have a > parent generic "Volume" containing just basic functions (and a block > cache). This allows me to initiate a Journal with two Volumes, one for > the journal and one for the file system. Somehow I feel that this > solution is somewhat less elegant. What does everyone think? Am I > complicating things too much? 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. > Another question, I was implementing the second recovery pass of the > journal (finding revoke blocks) and I read in the Linux implementation > that it uses a hash table. Should I follow this implementation, or try > something else? I thought about initially just doing a simple linked > list, and then later on choosing a proper cache technique, maybe even > reusing something already in Haiku. 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. > I'm not sure how responsible I must be for these kind of design > decisions. However, I'd rather ask about everything to produce something > that fits nicely inside Haiku. 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. Bye, Axel.