From: Lukas Straub <lukasstraub2@web.de>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Linux FS Devel <linux-fsdevel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
linux-raid@vger.kernel.org
Subject: Re: [dm-devel] Proper way to test RAID456?
Date: Sat, 8 Jan 2022 20:29:22 +0000 [thread overview]
Message-ID: <20220108202922.6b00de19@gecko> (raw)
In-Reply-To: <20220108195259.33e9bdf0@gecko>
[-- Attachment #1.1: Type: text/plain, Size: 1822 bytes --]
On Sat, 8 Jan 2022 19:52:59 +0000
Lukas Straub <lukasstraub2@web.de> wrote:
> CC'ing linux-raid mailing list, where md raid development happens.
> dm-raid is just a different interface to md raid.
>
> On Fri, 7 Jan 2022 10:30:56 +0800
> Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
> > Hi,
> >
> > Recently I'm working on refactor btrfs raid56 (with long term objective
> > to add proper journal to solve write-hole), and the coverage of current
> > fstests for btrfs RAID56 is not that ideal.
> >
> > Is there any project testing dm/md RAID456 for things like
> > re-silvering/write-hole problems?
> >
> > And how you dm guys do the tests for stacked RAID456?
> >
> > I really hope to learn some tricks from the existing, tried-and-true
> > RAID456 implementations, and hopefully to solve the known write-hole
> > bugs in btrfs.
Just some thoughts:
Besides the journal to mitigate the write-hole, md raid has another
trick:
The Partial Parity Log
https://www.kernel.org/doc/html/latest/driver-api/md/raid5-ppl.html
When a stripe is partially updated with new data, PPL ensures that the
old data in the stripe will not be corrupted by the write-hole. The new
data on the other hand is still affected by the write hole, but for
btrfs that is no problem.
But there is a even simpler solution for btrfs: It could just not touch
stripes that already contain data.
The big problem will be NOCOW files, since a write to an already
allocated extent will necessarily touch a stripe with old data in it
and the new data also needs to be protected from the write-hole.
Regards,
Lukas Straub
> > Thanks,
> > Qu
> >
> >
> > --
> > dm-devel mailing list
> > dm-devel@redhat.com
> > https://listman.redhat.com/mailman/listinfo/dm-devel
> >
>
>
>
--
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 97 bytes --]
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
WARNING: multiple messages have this Message-ID (diff)
From: Lukas Straub <lukasstraub2@web.de>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Linux FS Devel <linux-fsdevel@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
linux-raid@vger.kernel.org
Subject: Re: [dm-devel] Proper way to test RAID456?
Date: Sat, 8 Jan 2022 20:29:22 +0000 [thread overview]
Message-ID: <20220108202922.6b00de19@gecko> (raw)
In-Reply-To: <20220108195259.33e9bdf0@gecko>
[-- Attachment #1: Type: text/plain, Size: 1822 bytes --]
On Sat, 8 Jan 2022 19:52:59 +0000
Lukas Straub <lukasstraub2@web.de> wrote:
> CC'ing linux-raid mailing list, where md raid development happens.
> dm-raid is just a different interface to md raid.
>
> On Fri, 7 Jan 2022 10:30:56 +0800
> Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
> > Hi,
> >
> > Recently I'm working on refactor btrfs raid56 (with long term objective
> > to add proper journal to solve write-hole), and the coverage of current
> > fstests for btrfs RAID56 is not that ideal.
> >
> > Is there any project testing dm/md RAID456 for things like
> > re-silvering/write-hole problems?
> >
> > And how you dm guys do the tests for stacked RAID456?
> >
> > I really hope to learn some tricks from the existing, tried-and-true
> > RAID456 implementations, and hopefully to solve the known write-hole
> > bugs in btrfs.
Just some thoughts:
Besides the journal to mitigate the write-hole, md raid has another
trick:
The Partial Parity Log
https://www.kernel.org/doc/html/latest/driver-api/md/raid5-ppl.html
When a stripe is partially updated with new data, PPL ensures that the
old data in the stripe will not be corrupted by the write-hole. The new
data on the other hand is still affected by the write hole, but for
btrfs that is no problem.
But there is a even simpler solution for btrfs: It could just not touch
stripes that already contain data.
The big problem will be NOCOW files, since a write to an already
allocated extent will necessarily touch a stripe with old data in it
and the new data also needs to be protected from the write-hole.
Regards,
Lukas Straub
> > Thanks,
> > Qu
> >
> >
> > --
> > dm-devel mailing list
> > dm-devel@redhat.com
> > https://listman.redhat.com/mailman/listinfo/dm-devel
> >
>
>
>
--
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-01-08 20:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-07 2:30 [dm-devel] Proper way to test RAID456? Qu Wenruo
2022-01-07 2:30 ` Qu Wenruo
2022-01-08 19:52 ` [dm-devel] " Lukas Straub
2022-01-08 19:52 ` Lukas Straub
2022-01-08 20:29 ` Lukas Straub [this message]
2022-01-08 20:29 ` Lukas Straub
2022-01-08 23:55 ` Qu Wenruo
2022-01-08 23:55 ` Qu Wenruo
2022-01-09 10:04 ` David Woodhouse
2022-01-09 10:04 ` David Woodhouse
2022-01-09 12:13 ` Qu Wenruo
2022-01-09 12:13 ` Qu Wenruo
2022-01-12 16:56 ` Lukas Straub
2022-01-12 16:56 ` Lukas Straub
2022-01-13 1:30 ` Qu Wenruo
2022-01-13 1:30 ` Qu Wenruo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220108202922.6b00de19@gecko \
--to=lukasstraub2@web.de \
--cc=dm-devel@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.