Re: Question regarding to store file system metadata in database

[Ming Zhang <mingz@ele.uri.edu>]

On Sun, 2006-03-19 at 15:45 -0500, Ian Young wrote:
> Indeed. I think the issue here is that someone doesn't grasp that the
> filesystem is already a database: that in fact path and filenames are
> already metadata, with inode as the pkey, and they are indexed by
> linked lists, b-trees, or hashtables,  just as you might have going on
> inside the "black box" that is a database. The problem is that he
> thinks databases are somehow different because you use SQL to interact
> with them, when in fact the very same things that go on in
> filesystems, are going on in databases, just that with a database, you
> have strict pre-set agreements about what you'll be storing, so you
> can lay it out on-disk more efficiently. In a filesystem, there's no
> guarantee, or way to guarantee "this group of things will always be
> written in 256-word chunks", so it seems like something you could
> optimise using "a database" but it only shows ignorance of what
> exactly databases do. And... I'm fairly sure someone could write a
> SQL-like 'find' implementation in userland, and then you could query
> your "Database".

agree. all fancy/complex algorithm and data structures like trees are
used here already. and with some file systems get ACID as well, it can
be called as a database, if someone really want to call it in that
name. ;)


> 
> A better suggestion would be along the lines of "why don't we
> standardize a common set of metadata types to expand on directory,
> filename, size, mtime, ctime, atime, owner, and group? Why not 'type'
> 'title' 'author' 'revision' 'comment' 'icon' 'readers' 'writers'
> 'executors' 'checksum' etc.. etc...?" Now, THAT's something I'd like
> to see. 

that is why we have VFS right?


> 
> 
> Al Viro wrote: 
> > On Sun, Mar 19, 2006 at 01:50:22PM -0500, Xin Zhao wrote:
> >   
> > > Last, database-based file system is not so complex. As first step, I
> > > am just proposing to store pathanem-to-inode number in database. So it
> > > is basically a simple table. We don't really need any fancy features
> > > provided by db system. That's why I said a reduced  db system is
> > > enough. So the only difference betwen db-based file system and a
> > > regular one is that regular file system use directory file to store
> > > entries, but db-based file system use database to achieve the same
> > > goal. Looks like db will be a more efficient way. ;-)
> > >     
> > 
> > Define "database".  And explain how any of existing filesystems manages
> > to _not_ qualify your definition.
> > 
> > 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.
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> >   

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/