public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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