[haiku-development] Re: [gsoc2011] New File System
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Mon, 28 Mar 2011 12:38:40 +0200
On 2011-03-27 at 22:22:59 [+0200], Clemens <clemens.zeidler@xxxxxxxxxxxxxx>
wrote:
> On Mon, 28 Mar 2011 08:10:11 +1300, Ankur Sethi <get.me.ankur@xxxxxxxxx>
> wrote:
> > In any case, I'm looking at "modern" file systems for ideas. I'll
> > hopefully have a reasonable design doc in a day or two. I'm especially
> > interested in how other file systems handle attributes. Almost every
> > FS I've looked at supports extended attributes, but I'm not sure how
> > many of them actually index them for fast querying.
>
> I think NTFS is doing something like this, right?
According to the "Windows Search" Wikipedia article indexing and querying
is implemented in a service that listens for file system notifications.
> IMHO the index should be in userland. In this way you can have add-ons for
> different types of indices. For example, you might want to update the
> fulltext indexer for some new supported file format, doing that in the fs
> is quit dangerous and not very handy. By the way I rewrote the index
> server (its in the tree now), the server supports add-ons and is able to
> catch up its work from a time when it was not running. In this way you are
> able to stop the indexer for a while, e.g when compiling the haiku source
> and start it again later. This could speed up io critical stuff!
Performing the indexing in a dedicated index server alone could speed up
operations, since the thread doing the original file operation can continue
immediately instead of having to do the index maintenance synchronously. I
don't know, if this could lead to a problematic backlog. Probably not. If
so, automatically adjusting (IO) priorities might already fix the issue.
> The main problem is how does the index stay in sync with the file system.
> The current index server does not handle file modifications very effective
> this needs some more work. Furthermore, when a file is deleted we just get
> a node but in theory we need the path of the deleted file...
>
> One solution for the sync problem is to log every operation in the fs. The
> indexer would just need to look into this log to see whats happened
> recently/ when it was not running.
AFAIK, MacOS X has something like a global log. If the future Haiku FS is
based on btrfs or logfs we might even get that for free.
> >> Regarding changing the file system interface, that is a necessity and
> >> absolutely desired. E.g. we understand now that queries should not be
> >> implemented in the file system, but rather moved to a userland service.
> >
> > I don't understand: do you mean it would be better to parse the query
> > in a userland process and then pass it on to the filesystem[2]? Or do
> > you want to entirely move metadata handling to the userland?
> >
>
> Attributes in files system but index in userland.
Exactly.
> By the way an attribute array is missing in bfs!
It isn't only missing in BFS, but in the whole API as well.
CU, Ingo
Other related posts:
