From: David Chinner <dgc@sgi.com>
To: David Chinner <dgc@sgi.com>
Cc: Neil Brown <neilb@suse.de>, Avi Kivity <avi@argo.co.il>,
david@lang.hm, linux-kernel@vger.kernel.org,
linux-raid@vger.kernel.org
Subject: Re: limits on raid
Date: Thu, 21 Jun 2007 21:00:12 +1000 [thread overview]
Message-ID: <20070621110006.GU85884050@sgi.com> (raw)
In-Reply-To: <20070621063936.GT85884050@sgi.com>
On Thu, Jun 21, 2007 at 04:39:36PM +1000, David Chinner wrote:
> FWIW, I don't think this really removes the need for a filesystem to
> be able to keep multiple copies of stuff about. If the copy(s) on a
> device are gone, you've still got to have another copy somewhere
> else to get it back...
Speaking of knowing where you can safely put multiple copies, I'm in
the process of telling XFS about linear alignment of the underlying
array so that we can:
- spread out the load across it faster.
- provide workload isolation
- know where *not* to put duplicate or EDAC data
I'm aiming at identical subvolumes so it's simple to implement. All
I need to know is the size of each subvolume. I can supply that at
mkfs time or in a mount option, but I want something that can works
automatically so I need to query dm to find out the size of each
underlying device during mount. We should also pass stripe
unit/width with the same interface while we are at it...
What's the correct and safe way to get this information from dm
both into the kernel and out to userspace (mkfs)?
FWIW, my end goal is to be able to map the underlying block device
address spaces directly into the filesystem so that the filesystem
is able to use the underlying devices intelligently and I can
logically separate caches and writeback for the separate subdevices.
A struct address_space per subdevice would be ideal - anyone got
ideas on how to get that?
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
next prev parent reply other threads:[~2007-06-21 11:00 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-15 2:58 limits on raid david
2007-06-15 3:05 ` Neil Brown
2007-06-15 3:43 ` david
2007-06-15 3:58 ` Neil Brown
2007-06-15 9:13 ` David Chinner
2007-06-15 22:21 ` Neil Brown
2007-06-15 11:10 ` Avi Kivity
2007-06-15 16:23 ` Jan Engelhardt
2007-06-15 17:20 ` Avi Kivity
2007-06-15 21:59 ` Neil Brown
2007-06-16 17:23 ` Avi Kivity
2007-06-17 13:00 ` Andi Kleen
2007-06-18 4:57 ` David Chinner
2007-06-21 2:56 ` Neil Brown
2007-06-21 6:39 ` David Chinner
2007-06-21 6:45 ` david
2007-06-21 8:59 ` David Greaves
2007-06-21 17:00 ` Mark Lord
2007-06-21 11:00 ` David Chinner [this message]
2007-06-21 12:40 ` Mattias Wadenstein
2007-06-21 14:40 ` Justin Piszcz
2007-06-21 16:48 ` david
2007-06-21 18:30 ` Martin K. Petersen
2007-06-21 20:08 ` Nix
2007-06-16 2:03 ` Wakko Warner
2007-06-16 3:47 ` Neil Brown
2007-06-16 4:40 ` Dan Merillat
2007-06-16 7:48 ` david
2007-06-16 13:38 ` David Greaves
2007-06-16 17:16 ` david
2007-06-17 17:16 ` Bill Davidsen
2007-06-18 17:20 ` Brendan Conoboy
2007-06-18 17:28 ` david
2007-06-18 18:03 ` Lennart Sorensen
2007-06-18 18:12 ` david
2007-06-18 18:33 ` Lennart Sorensen
2007-06-18 18:40 ` david
2007-06-18 19:11 ` Brendan Conoboy
2007-06-18 20:52 ` david
2007-06-18 21:46 ` Wakko Warner
2007-06-18 21:56 ` david
2007-06-18 22:00 ` Brendan Conoboy
2007-06-19 20:11 ` Lennart Sorensen
2007-06-19 20:51 ` david
2007-06-19 15:07 ` Phillip Susi
2007-06-19 19:28 ` david
2007-06-18 18:07 ` Brendan Conoboy
2007-06-18 18:16 ` david
2007-06-16 13:33 ` David Greaves
2007-06-17 1:44 ` dean gaudet
2007-06-21 3:01 ` Neil Brown
2007-06-21 8:49 ` David Greaves
2007-06-16 14:08 ` Wakko Warner
2007-06-17 1:47 ` dean gaudet
2007-06-17 13:28 ` Wakko Warner
2007-06-17 17:28 ` dean gaudet
2007-06-17 19:30 ` Wakko Warner
2007-06-17 19:54 ` dean gaudet
2007-06-17 20:46 ` david
2007-06-17 20:44 ` david
2007-06-17 17:14 ` Bill Davidsen
2007-06-21 23:03 ` Bill Davidsen
2007-06-22 2:24 ` Neil Brown
2007-06-22 8:10 ` David Greaves
2007-06-22 9:51 ` david
2007-06-22 12:39 ` David Greaves
2007-06-22 16:00 ` Bill Davidsen
2007-06-22 16:55 ` David Greaves
2007-06-22 18:41 ` david
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=20070621110006.GU85884050@sgi.com \
--to=dgc@sgi.com \
--cc=avi@argo.co.il \
--cc=david@lang.hm \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.