>
> I guess my real question should have been, IF it turns out that quick
> indexing and the like are really the next hot thing, would ZFS support
> it (yes from what i gathered earlier on this list).
>
> <rant mode>Come to think of it, the biggest difference of putting this
> info in the FS layer or in a seperate DB would be availabilty. If the
> extra metadata is placed in the FS, as 'extra info' for files, then you
> have it in a DB right then and there, quickly accessible without having
> to run any daemons.
You also have now tied the indexing and index db management to fs ops along
with all the baggage it brings (code and memory size for parsing documents,
document parser extensions, index db btree ops, blocking or indexing thread
management, index lock spinning, ...).
> Now you have to scan files keep them in a seperate
> db, and keep that db up to date.
That DB would either be a new file in the fs or another type of data store
managed by the fs -- either way you have the same overhead as a userspace
daemon would. I can tell you that both MS and Google's desktop search
product line had a _ton_ of work put in to a; make sure that the default
search index priority did not "slow down" normal end user experience and b;
is very tunable to the point of being off (no-op). When coupled directly
into the fs layer you are stuck doing this in threads (if not blocking) and
on a heavy used system where these are tuned down could become quite a
challenge to manage.
> I can see why the guys over at namesys
> would want to do that, with all this 'searching' going on nowadays. I
> don't need to search that much myself. I usually keep my stuff organized
> enough to quickly find what I need.
Interestingly enough I view the server/desktop search market as being
formed behind the userspace camp already -- what seems to be on the horizon
is the share search space. Servers and desktops replying to search
requests as a grid. Looking at this level of search requires a userland
daemon.
> But if you look at it from a Windows
> point of view: Why was the 'smart start menu' introduced you think? The
> start menu always ends up a mess. Install 1 app, your start menu gets
> loaded with crap. even after a clean fresh install it's loaded with
> crap/unstructured. The 'smart' start menu was supposed to solve that by
> only showing the most rescent items and 'hiding' the rest. Then they
> came with the most used apps in the main menu, cause the desktop clearly
> wasn't usable for that anymore, as it was loaded with icons from users.
> And quicklaunch seems to be unused/disapeard because of that same
> reason. So I can see why desktop search and the like is getting so
> popular, people make a mess out of their system, requiring tool/methods
> to find stuff again. Anyway, this isn't really the right place to rant
> right :) </rant mode>
Search (server and desktop) has many uses -- finding apps to quickly launch
is for sure one. To view MS's attempt to closely tie FS and search go boot
up Vista and play around with WINFS -- err nevermind. I do not hold
Windows (XP or Vista) up as the bar to beat though and would prefer not to
quibble about their failed attempts.
-Wade
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
