From: Ming Zhang <mingz@ele.uri.edu>
To: Xin Zhao <uszhaoxin@gmail.com>
Cc: mikado4vn@gmail.com, linux-kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: Question regarding to store file system metadata in database
Date: Sun, 19 Mar 2006 12:58:40 -0500 [thread overview]
Message-ID: <1142791121.31358.21.camel@localhost.localdomain> (raw)
In-Reply-To: <4ae3c140603190948s4fcd135er370a15003a0143a8@mail.gmail.com>
database can reside on a raw block device.
but 300 metadata iops is not that fast. ;)
ming
On Sun, 2006-03-19 at 12:48 -0500, Xin Zhao wrote:
> well, the database could reside on another file system. So the
> database based file system could be a secondary file system but
> provide more features and better performance. I am not saying that
> database-based file system must be the only filesystem on the system.
>
> On 3/19/06, Mikado <mikado4vn@gmail.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Where is that database located, on other filesystem or on database-based
> > filesystem?
> >
> > Xin Zhao wrote:
> > > I was wondering why only few file system uses database to store file
> > > system metadata. Here, metadata primarily refers to directory entries.
> > > For example, one can setup a database to store file pathname, its
> > > inode number, and some extended attribution. File pathname can be used
> > > as primary key. As such, we can achieve pathname to inode mapping as
> > > well as many other features such as fast search and extended file
> > > attribute management. In contrast, storing file system entries in
> > > directory files may result in slow dentry search. I guess that's why
> > > ReiserFS and some other file systems proposed to use B+ tree like
> > > strucutre to manage file entries. But why not simple use database to
> > > provide the same feature? DB has been heavily optimized to provide
> > > fast search and should be good at managing metadata.
> > >
> > > I guess one concern about this idea is performance impact caused by
> > > database system. I ran a test on a mysql database: I inserted about
> > > 1.2 million such kind of records into an initially empty mysql
> > > database. Average insertion rate is about 300 entries per second,
> > > which is fast enough to handle normal file system burden, I think. I
> > > haven't try the query speed, but I believe it should be fast enough
> > > too (maybe I am wrong, if so, please point that out.).
> > >
> > > Then I am a little curious why only few people use database to store
> > > file system metadata, although I know WinFS plans to use database to
> > > manage metadata. I guess one reason is that it is difficult for kernel
> > > based file system driver to access database. But this could be
> > > addressed by using efficient kernel/user communication mechanism.
> > > Another reason could be the worry about database system. If database
> > > system crashes, file system will stop functioning too. However, the
> > > feature needed by file system is really a small part of database
> > > system, A reduced database system should be sufficient to provide this
> > > feature and be stable enough to support a file system.
> > >
> > > Can someone point out more issues that could become obstables to using
> > > database to manage metadata for a file system?
> > >
> > > Many thanks!
> > > Xin
> > > -
> > > 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/
> > >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.2.1 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFEHOceNWc9T2Wr2JcRAsKKAJ9t1fRZ1xczAaeruDUqTNeLMcGuiwCfeTNt
> > 31pFUK79Q7BE1AptbmNqr9Q=
> > =LbiF
> > -----END PGP SIGNATURE-----
> >
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2006-03-19 17:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-19 4:48 Question regarding to store file system metadata in database Xin Zhao
2006-03-19 5:07 ` Mikado
2006-03-19 17:48 ` Xin Zhao
2006-03-19 17:58 ` Ming Zhang [this message]
2006-03-19 18:11 ` Xin Zhao
2006-03-19 18:26 ` Ming Zhang
2006-03-19 18:50 ` Xin Zhao
2006-03-19 19:47 ` Al Viro
[not found] ` <441DC2D6.4060001@societasilluminati.org>
2006-03-19 21:24 ` Ming Zhang
2006-03-20 13:09 ` Theodore Ts'o
2006-03-20 15:13 ` Xin Zhao
2006-03-20 19:36 ` Xin Zhao
2006-03-20 19:58 ` Al Viro
2006-03-20 22:53 ` Xin Zhao
2006-03-20 23:32 ` Al Viro
2006-03-20 21:08 ` Matti Aarnio
2006-03-20 22:28 ` Erez Zadok
2006-03-20 22:19 ` Theodore Ts'o
2006-03-21 6:51 ` Miklos Szeredi
2006-03-21 20:05 ` Pavel Machek
2006-03-22 15:21 ` Xin Zhao
2006-03-19 21:34 ` Ming Zhang
2006-03-20 8:30 ` Matti Aarnio
2006-03-19 23:06 ` Alan Cox
2006-03-19 23:44 ` Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1142791121.31358.21.camel@localhost.localdomain \
--to=mingz@ele.uri.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikado4vn@gmail.com \
--cc=uszhaoxin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).