raild[56] again

raild[56] again

[Roy Sigurd Karlsbakk]

Hi all

Is raid[56] coming to btrfs? There was some talk about it a year back o=
r so, but I haven't seen anything yet....

Best regards

roy
--
Roy Sigurd Karlsbakk
(+47) 97542685
roy@karlsbakk.net
http://blogg.karlsbakk.net/
--
I all pedagogikk er det essensielt at pensum presenteres intelligibelt.=
 Det er et element=C3=A6rt imperativ for alle pedagoger =C3=A5 unng=C3=A5=
 eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste ti=
lfeller eksisterer adekvate og relevante synonymer p=C3=A5 norsk.
--
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

Re: raild[56] again

[Tomasz Torcz]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

On Mon, May 03, 2010 at 10:02:10PM +0200, Roy Sigurd Karlsbakk wrote:
> Hi all
> 
> Is raid[56] coming to btrfs? There was some talk about it a year back or so, but I haven't seen anything yet....

  Look again, there was an email just few days ago:
3705     Apr 29 David Woodhouse ( 13K) Updating RAID[56] support

-- 
Tomasz Torcz              ,,If you try to upissue this patchset I shall be seeking
xmpp: zdzichubg@chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton (LKML)


[-- Attachment #2: Type: application/pgp-signature, Size: 238 bytes --]

Re: raild[56] again

[David Woodhouse]

On Mon, 2010-05-03 at 22:02 +0200, Roy Sigurd Karlsbakk wrote:
> Is raid[56] coming to btrfs? There was some talk about it a year back
> or so, but I haven't seen anything yet....

Um, there was some talk about it about four days ago. You even
participated in that thread!

As it stands, it has the traditional 'write hole' problem -- when you
overwrite _part_ of a stripe, you have to update the parity block(s) too
and you have a short period of time where the parity doesn't match the
actual data. If you get a crash followed by a disk failure during that
period of time, you get data loss.

The solution is always to write a full stripe (across all the disks in
the set). Chris said he'd sort that out in the upper layers of btrfs,
about which I know little. We've been waiting a while for that.

I poked him recently and we realised that I hadn't actually made my part
_cope_ with being given a full stripe at a time, which was a bit of an
oversight. I had done it once as a test, but had never actually
committed and pushed that support. The patch I posted last week attempts
to fix that. There are one or two details I wanted some feedback on but
in the absence of that, I think I'll just tidy it up and push it using
the existing approach.

-- 
dwmw2

Re: raild[56] again

[Chris Mason]

On Tue, May 04, 2010 at 04:09:09PM +0100, David Woodhouse wrote:
> On Mon, 2010-05-03 at 22:02 +0200, Roy Sigurd Karlsbakk wrote:
> > Is raid[56] coming to btrfs? There was some talk about it a year back
> > or so, but I haven't seen anything yet....
> 
> Um, there was some talk about it about four days ago. You even
> participated in that thread!
> 
> As it stands, it has the traditional 'write hole' problem -- when you
> overwrite _part_ of a stripe, you have to update the parity block(s) too
> and you have a short period of time where the parity doesn't match the
> actual data. If you get a crash followed by a disk failure during that
> period of time, you get data loss.
> 
> The solution is always to write a full stripe (across all the disks in
> the set). Chris said he'd sort that out in the upper layers of btrfs,
> about which I know little. We've been waiting a while for that.

Yeah, I've got it nailed down for data and metadata here, and I'm
integrating all these development patches into one branch (O_DIRECT
etc, raid, zheng's work).

-chris