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 ([EMAIL PROTECTED]) http://www.flamingspork.com/
signature.asc
Description: This is a digitally signed message part
