From: Chris Murphy <lists@colorremedies.com>
To: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Cc: Chris Murphy <lists@colorremedies.com>,
Qu Wenruo <quwenruo@cn.fujitsu.com>,
Hugo Mills <hugo@carfax.org.uk>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
Austin Hemmelgarn <ahferroin7@gmail.com>
Subject: Re: RAID system with adaption to changed number of disks
Date: Fri, 14 Oct 2016 15:38:48 -0600 [thread overview]
Message-ID: <CAJCQCtQCRiM2MPJt9cwQC37tTJiJoiZj5X5bwg-NDxpNaLvB7g@mail.gmail.com> (raw)
In-Reply-To: <20161014195544.GZ21290@hungrycats.org>
On Fri, Oct 14, 2016 at 1:55 PM, Zygo Blaxell
<ce3g8jdj@umail.furryterror.org> wrote:
>
>> And how common is RMW for metadata operations?
>
> RMW in metadata is the norm. It happens on nearly all commits--the only
> exception seems to be when both ends of a commit write happen to land
> on stripe boundaries accidentally, which is less than 1% of the time on
> 3 disks.
In the interest of due diligence, and the fact I can't confirm or deny
this myself from reading the code (although I do see many comments
involving RMW in the code), I must ask Qu if he can corroborate this.
Because basically means btrfs raid56 is not better than md raid56 - by
design. It has nothing to do with bugs. This is substantially worse
than the scrub->wrong parity bug.
Does it make sense to proscribe raid5 profile for metadata? As in,
disallow -m raid5 at mkfs time? Maybe recommend raid1. Even raid6
seems like it could be specious - yes there are two copies but if
there is constant RMW, then there's no CoW and we're not really
protected that well with all of these overwrites, statistically
speaking.
Basically you have to have a setup where there's no chance of torn or
misdirected writes, and no corruptions, in which case Btrfs checksums
aren't really helpful, you're using it for other reasons (snapshots
and what not).
Really seriously the CoW part of Btrfs being violated by all of this
RMW to me sounds like it reduces the pros of Btrfs.
--
Chris Murphy
next prev parent reply other threads:[~2016-10-14 21:38 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-11 15:14 RAID system with adaption to changed number of disks Philip Louis Moetteli
2016-10-11 16:06 ` Hugo Mills
2016-10-11 23:58 ` Chris Murphy
2016-10-12 1:32 ` Qu Wenruo
2016-10-12 4:37 ` Zygo Blaxell
2016-10-12 5:48 ` Qu Wenruo
2016-10-12 17:19 ` Zygo Blaxell
2016-10-12 19:55 ` Adam Borowski
2016-10-12 21:10 ` Zygo Blaxell
2016-10-13 3:40 ` Adam Borowski
2016-10-12 20:41 ` Chris Murphy
2016-10-13 0:35 ` Qu Wenruo
2016-10-13 21:03 ` Zygo Blaxell
2016-10-14 1:24 ` Qu Wenruo
2016-10-14 7:16 ` Chris Murphy
2016-10-14 19:55 ` Zygo Blaxell
2016-10-14 21:19 ` Duncan
2016-10-14 21:38 ` Chris Murphy [this message]
2016-10-14 22:30 ` Chris Murphy
2016-10-15 3:19 ` Zygo Blaxell
2016-10-12 7:02 ` Anand Jain
2016-10-12 7:25 ` Roman Mamedov
2016-10-12 17:31 ` Zygo Blaxell
2016-10-12 19:19 ` Zygo Blaxell
2016-10-12 19:33 ` Roman Mamedov
2016-10-12 20:33 ` Zygo Blaxell
2016-10-11 16:37 ` Austin S. Hemmelgarn
2016-10-11 17:16 ` Tomasz Kusmierz
2016-10-11 17:29 ` ronnie sahlberg
2016-10-12 1:33 ` Dan Mons
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=CAJCQCtQCRiM2MPJt9cwQC37tTJiJoiZj5X5bwg-NDxpNaLvB7g@mail.gmail.com \
--to=lists@colorremedies.com \
--cc=ahferroin7@gmail.com \
--cc=ce3g8jdj@umail.furryterror.org \
--cc=hugo@carfax.org.uk \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).