From: Goffredo Baroncelli <kreijack@inwind.it>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>
Cc: Chris Murphy <lists@colorremedies.com>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
Zygo Blaxell <zblaxell@furryterror.org>
Subject: Re: RFC: raid with a variable stripe size
Date: Tue, 29 Nov 2016 19:19:25 +0100 [thread overview]
Message-ID: <33049d04-a0b3-8a71-7ab1-6993a63ca07d@inwind.it> (raw)
In-Reply-To: <cf02a446-f83d-0d4b-2b60-70a99e18ab39@cn.fujitsu.com>
On 2016-11-29 07:03, Qu Wenruo wrote:
[...]
>> Btrfs is subject to the write hole problem on disk, but any read or
>> scrub that needs to reconstruct from parity that is corrupt results in
>> a checksum error and EIO. So corruption is not passed up to user
>> space. Recent versions of md/mdadm support a write journal to avoid
>> the write hole problem on disk in case of a crash.
>
> That's interesting.
>
> So I think it's less worthy to support RAID56 in btrfs, especially considering the stability.
>
> My widest dream is, btrfs calls device mapper to build a micro RAID1/5/6/10 device for each chunk.
> Which should save us tons of codes and bugs.
>
> And for better recovery, enhance device mapper to provide interface to judge which block is correct.
>
> Although that's just dream anyway.
IIRC in the past this was discussed, although I am not able to find any reference...
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
next prev parent reply other threads:[~2016-11-29 18:19 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-18 18:15 RFC: raid with a variable stripe size Goffredo Baroncelli
2016-11-18 20:32 ` Janos Toth F.
2016-11-18 20:51 ` Timofey Titovets
2016-11-18 21:38 ` Janos Toth F.
2016-11-19 8:55 ` Goffredo Baroncelli
2016-11-18 20:34 ` Timofey Titovets
2016-11-19 8:59 ` Goffredo Baroncelli
2016-11-19 8:22 ` Zygo Blaxell
2016-11-19 9:13 ` Goffredo Baroncelli
2016-11-29 0:48 ` Qu Wenruo
2016-11-29 3:53 ` Zygo Blaxell
2016-11-29 4:12 ` Qu Wenruo
2016-11-29 4:55 ` Zygo Blaxell
2016-11-29 5:49 ` Qu Wenruo
2016-11-29 18:47 ` Janos Toth F.
2016-11-29 22:51 ` Zygo Blaxell
2016-11-29 5:51 ` Chris Murphy
2016-11-29 6:03 ` Qu Wenruo
2016-11-29 18:19 ` Goffredo Baroncelli [this message]
2016-11-29 22:54 ` Zygo Blaxell
2016-11-29 18:10 ` Goffredo Baroncelli
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=33049d04-a0b3-8a71-7ab1-6993a63ca07d@inwind.it \
--to=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=quwenruo@cn.fujitsu.com \
--cc=zblaxell@furryterror.org \
/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.