Re: Question regarding to store file system metadata in database

[Theodore Ts'o <tytso@mit.edu>]

On Sun, Mar 19, 2006 at 07:47:23PM +0000, Al Viro wrote:
> As for "more efficient"...  300 lookups per second is less than an
> improvement.  It's orders of magnitude worse than e.g. ext2; I don't
> know in which world that would be considered more efficient, but I
> certainly glad that I don't live there.

There are two problems... well, more, but in the performance domain,
at least two issues that stick out like a sore thumb.

The first is throughput, and as Al and others have already pointed out
300 metadata operations per second is defintely nothing to write home
about.  The second is latency; how much *time* does it take to perform
an individual operations, especially if you have to do an upcall from
the kernel to a userspace database process, the user space process
then has to dick around its own general purpose,
non-optimized-for-a-filesystem data structures, possibly make syscalls
back down into the kernel only to have the data blocks pushed back up
into userspace, and then finally return the result of the "stat"
system call back to the kernel so the kernel can ship it off to the
original process that called stat(2).

Even in WinFS, dropped from Microsoft Longwait, it really wasn't using
the database to store all metadata.  A better way of thinking about it
is a forcible bundling of a Microsoft's database product (European
regulators take note) with the OS; all of the low-level filesystem
operations are still being done the traditional way, and it's only
high level indexing operation which are being done in userspace (and
only in userspace).  It would be like taking the taking the locate(1)
userspace program and claiming it was part of the filesystem; it's
more about packaging than anything else.

						- Ted