Re: Longhorn FS being removed to Blackcomb (end of decade)

[Stewart Smith <stewart@flamingspork.com>]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

On Sat, 2004-04-10 at 05:33, Jonathan Briggs wrote:
> I think the best way to be doing database features is with a fast,
> robust file change notification feature, and do the database in user
> space.  Some filesystem features would be required, but I think metadata
> and two-way hard links is all we need.

Symbolic links would quite possibly work better - as then you can
extract the path of the original file, and with the manipulation of
these symlinks being part of the file manipulation atom (as in, an
atomic operation), consistency wouldn't be a problem.

> The daemon could watch directory creation and look for query metadata on
> directories.  When found, it would use index directories or full
> filesystem search to fill in the query results.

You have a lot of consistency problems here. Consider this:
1. process 1 creates file
2. kernel tells userspace to index it
CRASH

the userspace daemon hasn't had time to put it into the index. On
reboot, how do you get a list of files to insert into the index without
scanning every single file on disk (essentially a fsck)? You can't - so
you're in trouble. You could have a to-be-indexed directory of hard/sym
links where as the userspace utility flushes the index of the item to
disk, it is removed from there. That could work... but it requires the
creat() (etc) operations to also create this link atomically, otherwise
you could create the file, but not have it in the "to be indexed" list.

It's for these kinds of reasons that all the befs indexing stuff is all
in kernel.

-- 
Stewart Smith (stewart@flamingspork.com)
http://www.flamingspork.com/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]