On Wed, Dec 16, 2009 at 5:13 AM, Goswin von Brederlow [off-list ref] wrote:

Michael Evans [off-list ref] writes:

quoted

On Fri, Dec 11, 2009 at 11:22 PM, Kasper Sandberg
[off-list ref] wrote:

quoted

On Wed, 2009-12-09 at 11:53 +0100, Mikael Abrahamsson wrote:

quoted

On Wed, 9 Dec 2009, Michael Evans wrote:

while this could work, i would personally far rather see raid6 gain all
the recovery/sanity options possible. raid6 has multiple copies of the
same data, and as long as you have >2 copies, you can begin to look at
all the data sets, and with a pretty good probability weed out the bad
set.

While I would like to have a layer that any storage use, including
other raid levels, could reside within.  Imagine how much smarter
raid6 could be if it already knew in advance which stripes had gone
bad?  Or if files older than a few seconds could also gain an
additional 'bad sector' survival; allowing the loss of whatever normal
raid tolerances plus a bad sector or two.  It would not be required,
but I believe it would be a good way of adding assurance to long-term
storage segments.

I implore you to comment on the original suggestion, or my reply to
his reply as well.

I think that really belongs in the filesystem. You don't want to waste
parity on data that isn't in use and you want to be able to connect
bad data with the relevant files easily. So go use zfs or the like. :)

MfG
       Goswin

The same argument can be made for all current levels of RAID as well.
The primary reason we are still using RAID layers is that the majority
of, virtually all, filesystems currently in use lack the capacity.
Additionally it is likely that even with new maturing filesystems that
do support RAID style storage we will still need to rely on the
protection of RAID for backwards compatibility.

I do however agree that the goals of the current RAID system and even
potentially the algorithms for creating and recovering parity blocks
can, and should be, shared with any portion of the kernel; also
possibly even userspace via library abstraction (in the case of
hardware acceleration).  It only adds additional failure points to
have multiple copies of very similar procedures.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html