From: Mike Fedyk <mfedyk@matchmail.com>
To: "Ramy M. Hassan" <ramy@gawab.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Advanced storage management ( suggestion )
Date: Sat, 06 Mar 2004 19:34:13 -0800 [thread overview]
Message-ID: <404A9835.4020602@matchmail.com> (raw)
In-Reply-To: <003801c402ea$44437190$ba10a8c0@ramy>
Ramy M. Hassan wrote:
> 1- Very fast block allocation ( Using balanced trees for tracking free
> blocks comes into my mind now, but I still it is early to decide the
> design ).
You most likely want to use extents in addition to whatever else you use
(ie, trees/etc.).
> 2- Support for multi-disk/multi-host storage pool.
You're mixing layers here. MD and DM already work in this area.
> 3- Meta data storage and block storage can be isolated for better
> performance.
There is support for journal on a different device in the generic JBD
code that ext3 uses, and reiserfs (possibly others also). That may be a
good place to work from.
Are there any examples of this in other OSes? If you put the meta-data
on a separate drive, it would be an inherently seeky load. How does
this compare to putting raid below the mixed data and meta-data block
device?
> 4- Meta data and block replication options.
Coda and Intermezzo do this in a filesystem independent way already.
This can add flexibility.
> 5- Transactional options for journaling filesystems or transactional
> databases.
Isn't journaling inherently transaction based already?
> 6- Supports clustering through lock managers where multiple hosts can
> read/write to same storage devices concurrently ( suitable for SANs )
This is going to be a very heavy layer, and few people will use it if it
isn't very light (or can be configured that way)
> 7- Transparent recovery from corruption or hardware failure.
Journaling in ext3 is block based, and the rest are virtual
(descriptions of the actions are in the journal, not the entire block of
meta-data -- when you're not running in data journaling mode).
How do you plan on integrating your proposed layer with these two very
different approaches to filesystem journaling?
> 8- Direct access from userland ( for DBMS, LDAP, and other userland
> applications ).
You have a separate userspace, and kernel implementation right?
> 9- Plugins support ( like those of reiserfs 4).
This can be good or bad. Make sure it doesn't bloat your layer.
Mike
next prev parent reply other threads:[~2004-03-07 3:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-05 19:44 Advanced storage management ( suggestion ) Ramy M. Hassan
2004-03-07 3:34 ` Mike Fedyk [this message]
2004-03-07 4:30 ` Neil Brown
2004-03-07 6:08 ` Mike Fedyk
2004-03-09 16:38 ` Jeremy Jackson
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=404A9835.4020602@matchmail.com \
--to=mfedyk@matchmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ramy@gawab.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