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.... 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ært imperativ for alle pedagoger å unngå eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer på 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
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)
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 -- 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
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 -- 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