Date: Mon, 6 Apr 2009 15:18:54 +0200 From: Gabriele Modena <gabriele.modena@gmail.com> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC: Semantic File System Message-ID: <1fe1d5d60904060618j1f68b45fl7810169d66890fd6@mail.gmail.com> In-Reply-To: <alpine.BSF.2.00.0904021813110.94891@fledge.watson.org> References: <1fe1d5d60903210422g70efef15hdd685695cdf8df3c@mail.gmail.com> <alpine.BSF.2.00.0903221649590.51184@fledge.watson.org> <1fe1d5d60904020904ya6dcb00h54a54d6a00e2bd0@mail.gmail.com> <alpine.BSF.2.00.0904021813110.94891@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 2, 2009 at 7:26 PM, Robert Watson <rwatson@freebsd.org> wrote: >> In this moment I am considering also an userspace approach similar to >> Spotlight/Beagles, but I don't know how I could propose this as a FreeBSD >> GSoC project. > > I think that would make a fine GSoC proposal. Keep in mind that one of the > premises of Spotlight is the fsevents kernel feature, and fseventsd, which > allow Spotlight to subscribe to changes in trees and kick off reindexing as > required. Porting the fsevents API to FreeBSD is fairly straight forward, > with one exception: HFS+ offers a much more reliable notion of vnode->path > mapping, but it would be interesting to see how well our current vnode->path > mapping mechanisms would suffice in practice (since a lot of the edge cases > that don't work well with our mapping system are exactly that -- edge > cases). This is in case of using UFS/FFS as the base fs or is a more general VFS issue? And what about ZFS? Since apple has not (partially) started to support it, IMHO it may be an interesting fs to investigate. > Between kernel and userspace parts there's quite a bit to do, but one > possibility would be to borrow parts from Mac OS X/etc that we need. For > example, do a literal port of the fsevents mechanism from XNU, provide our > own implementation that provides a similar API, or provide a new mechanism > that meets fseventd's semantic requirements for monitoring. This would definitely be an interesting approach. One of my original ideas was to have a look at how inotify has been implemented in linux, but probably fsevents would be a better choice (also license wise). > I'm probably blending reality with imagination here, but my vague > recollection is that the model was a slightly different blend of user vs. > application involvement in indexing. For how I see it now the steps for my work could be: 1) port/implement an event notification feature; 2) build a userspace indexer; 3) write a gui/search tool on top of it. > In the BeOS model, or my reinterpretation based on something I read a long > time ago and then presumably had dreams about, the split is a bit different: > the file system maintains indexes of extended attributes, which are written > by applications in order to expose searchable material. This sounds to me like adding another layer/proxy between the applications and the actual data. I found some material about node watch and extended attributes that I'm going to study in these days. > It's also worth observing that one of the authors of BFS was Dominic > Giampaolo, who now works on Apple's HFS+, and implemented fsevents there as > part of their Spotlight project. Thanks a lot for you feedback, you provided me a with lot of very interesting material to look up! Cheers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1fe1d5d60904060618j1f68b45fl7810169d66890fd6>