[haiku-development] Re: gsoc2010: File systems

  • From: Janito Ferreira Filho <jvffprog@xxxxxxxxxxx>
  • To: Haiku Development <haiku-development@xxxxxxxxxxxxx>
  • Date: Thu, 1 Apr 2010 12:43:56 +0000

> axeld@xxxxxxxxxxxxxxxx wrote:
> Not using the file cache would be quite annoying, though (for 
> performance reasons, but also as currently only files with a file cache 
> can be mmap'ed).
> IOW I would either leave out using the log for file data (I believe 
> this is an option in ext3 as well), or not implement logging for now 
> (ie. only replay the log if necessary, and keep it that way).


I think it would be possible to do an initial implementation without data 
journaling (supporting the other two types of ext3 jorunaling). I suspect that 
to do data journaling it would be required to do some cached block duplication 
(or maybe implement a way of copy-on-write duplication) to prevent over-writing 
the cache before the transaction is committed. Thanks for showing me where the 
caches are, I'll look into it as soon as possible =).

> It's usually the best way to dig in once you have an overview about how 
> it should work. And in many cases (especially with Haiku), it's the 
> only way there is, due to lack of (up-to-date) documentation.

Ok. I guess it's also the best way to get the most technical info too. And I am 
enjoying much of the Haiku code. It's very clean, and looking at the Linux ext3 
code, I really prefer code without gotos (although I guess it's a matter of 
taste and efficiency trade-offs).

> Anyway, if you feel uncomfortable with just one application, you can 
> write as many applications as you want - it's just a good pile of work 
> to come up with a good one.

I thought about finding an alternative, however the more I researched into 
implementing ext3, the more I liked it =). If there's time I might look into 
other stuff.

> Usually, the thing you should start with is the allocator for new blocks 
> (and freeing blocks), because this will be needed for almost all 
> operations.
> With file data, you would just allow file data to be changed at known 
> positions, and then later would allow the file to grow/shrink.

Ok. It will definitely be the most used code for most meta-data operations. 
I'll just have to think about how to incorporate it into a transaction. 
Although I think the best idea would be just to pass a "Transaction*" as a 
parameter. I've already started reading the BeFS code, maybe I can get more 
insights there.

BTW, would it be a good idea (if I could finish it in time), add to the current 
ext2 mount code to read (and possibly replay, but without doing any writes to 
the hard-disk) an ext3 journal? I think it would be an opportunity for me to 
gain further experience with the ext3 journal implementation (although if I 
read correctly, there are two versions of the journal format; one is very old, 
and I think it's use is probably zero so I'm not sure it's worth trying to 
figure it out to implement it). Also, I think it might be an option for a patch 
to submit to be used on the GSOC application. Should I try to do it?

Thanks for your answers!


Hotmail: Free, trusted and rich email service.

Other related posts: