[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070621110006.GU85884050@sgi.com>
Date: Thu, 21 Jun 2007 21:00:12 +1000
From: David Chinner <dgc@....com>
To: David Chinner <dgc@....com>
Cc: Neil Brown <neilb@...e.de>, Avi Kivity <avi@...o.co.il>,
david@...g.hm, linux-kernel@...r.kernel.org,
linux-raid@...r.kernel.org
Subject: Re: limits on raid
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists