raild[56] again
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
[email protected]
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 3 lines · Roy Sigurd Karlsbakk
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
Signature · 2 lines
Tomasz Torcz ,,If you try to upissue this patchset I shall be seeking xmpp: [email protected] an IP-routable hand grenade.'' -- Andrew Morton (LKML)
Quoted 2 lines · Roy Sigurd Karlsbakk
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.
Signature · 1 line
dwmw2
Quoted 13 lines · David Woodhouse
Quoted 2 lines · Roy Sigurd Karlsbakk
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.
Quoted 3 lines
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