Re: [PATCH 1/4] md: Factor out RAID6 algorithms into lib/

[Dan Williams <dan.j.williams@intel.com>]

On Sat, Jul 18, 2009 at 4:53 AM, David Woodhouse<dwmw2@infradead.org> w=
rote:
> On Fri, 2009-07-17 at 11:49 -0400, H. Peter Anvin wrote:
>> Cost, yes, of changing an on-disk format.
>
> Personally, I don't care about that -- I'm utterly uninterested in th=
e
> legacy RAID-6 setup where it pretends to be a normal disk. I think th=
at
> model is as fundamentally wrong as flash devices making the similar
> pretence.

I can understand the frustration of these details being irretrievably
hidden behind a proprietary interface out of the filesystem's control.
 However, this is not the case with Linux software RAID.  I suspect
that there is room for more interaction with even "legacy" filesystems
to communicate things like: "don't worry about initializing that
region of the disk it's all free space", "don't bother resyncing on
dirty shutdown, if power-loss interrupts a write I guarantee I will
replay the entire stripe to you at a later date", or "hey, that last
block I read doesn't checksum, can you come up with a different
version?"

I was under the impression that btrfs wanted to leverage md's stripe
handling logic as well, seems that is not the case?

--
Dan

> =B9 Well, kind of. The xor_blocks() function will silently screw you =
over
> =A0if you ask it to handle more than 5 blocks at a time.

async_xor() handles arbitrary block counts.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html