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