From: Neil Brown <neilb@cse.unsw.edu.au>
To: Mike Fedyk <mfedyk@matchmail.com>
Date: Sun, 7 Mar 2004 15:30:58 +1100
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16458.42370.917655.953328@notabene.cse.unsw.edu.au>
Cc: "Ramy M. Hassan" <ramy@gawab.com>, linux-kernel@vger.kernel.org
Subject: Re: Advanced storage management ( suggestion )
In-Reply-To: message from Mike Fedyk on Saturday March 6
References: <003801c402ea$44437190$ba10a8c0@ramy>
	<404A9835.4020602@matchmail.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1270
Lines: 30

On Saturday March 6, mfedyk@matchmail.com wrote:
> 
> > 2- Support for multi-disk/multi-host storage pool.
> 
> You're mixing layers here.  MD and DM already work in this area.
> 

I would probably disagree here.
I think it makes much more sense for a filesystem to know about
multiple devices than for MD or DM to combine a bunch of devices into
the illusion of one big device, only to have the filesystem chop that
big device into little files....

(Note that I wouldn't expect a filesystem to include raid5 style
behaviour, and probably wouldn't expect raid1 like behaviour, but
having the filesystem do striping and inter-device migration itself
seems eminently sensible.)

However I don't see much value if the suggestion of a new layer that
provide lots of services of filesystems.  I strongly suspect that no
filesystem would want to use them.  Look at "jdb".  It is designed to
provide a journalling layer for any filesystem, but how many
filesystems use it?  Just one - ext3 - the one it was designed for.

NeilBrown
-
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/