From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.cz
Cc: linux-btrfs@vger.kernel.org, clm@fb.com
Subject: Re: [PATCH 0/2] [RFC] btrfs: create degraded-RAID1 chunks
Date: Mon, 2 May 2016 12:12:31 +0800 [thread overview]
Message-ID: <5726D3AF.5010103@oracle.com> (raw)
In-Reply-To: <20160429163727.GD29353@suse.cz>
On 04/30/2016 12:37 AM, David Sterba wrote:
> On Thu, Apr 28, 2016 at 11:06:18AM +0800, Anand Jain wrote:
>> From the comments that commit[1] deleted
>>
>> - /*
>> - * we add in the count of missing devices because we want
>> - * to make sure that any RAID levels on a degraded FS
>> - * continue to be honored.
>> - *
>>
>> appear to me that automatic reduced-chunk-allocation
>> when RAID1 is degraded wasn't in the original design.
>>
>> which also introduced unpleasant things like automatically
>> allocating single chunks when RAID1 is mounted in degraded
>> mode, which will hinder further RAID1 mount in degraded
>> mode.
>
> Agreed. As the automatic conversion cannot be turned off, it causes some
> surprises. We've opposed against such things in the past, so I'm for
> not doing the 'single' allocations. Independly, I got a feedback from a
> user who liked the proposed change..
yes.
>> And now to fix the original issue that is - chunk allocation
>> fails when RAID1 is degraded, The reason for the problem
>> seems to be that we had the devs_min attribute for RAID1
>> set wrongly. Correcting this also means that its time to
>> fix the RAID1 fixmes in the functions __btrfs_alloc_chunk()
>> patch [2] does that, and is for review.
>
> This means we'd allow full writes to a degraded raid1 filesystem. This
> can bring surprises as well. The question is what to do if the device
> pops out, some writes happen, and then is added.
> One option is to set some bit in the degraded filesystem that degraded
> writes happened.
> After that, mounting the whole filesystem would
> recommend running scrub before dropping the bit.
Right some flag should tell to fix the degraded chunks. Any
suggestion on naming? (as of now calling it degraded-chunk-write-flag).
Also as of now I think its ok to fail the mount when its found
that both of the RAID1 devices has degraded-chunk-write-flag set
(a split brain situation) so that user can mount one of the device
and freshly btrfs-device-add the other.
> Forcing a read-only
> mount here would be similar to read-only degraded mount, so I guess we'd
> have to somehow deal with the missing writes.
> I haven't thought about all details, the raid1 auto-repair can handle
> corrupted data, I think missing metadata should be handled as well and
> repaired.
I found raid5 scrub nicely handles the missing writes. However
RAID1 (and guess raid10 as well) needs balance. (I would like to
keep it as it is as of now). IMO RAID1 should do what RAID5 is doing.
> --
> 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
>
next prev parent reply other threads:[~2016-05-02 4:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-28 3:06 [PATCH 0/2] [RFC] btrfs: create degraded-RAID1 chunks Anand Jain
2016-04-28 3:06 ` [PATCH 1/2] " Anand Jain
2016-04-29 16:42 ` David Sterba
2016-05-02 6:10 ` Anand Jain
2016-05-10 11:00 ` Anand Jain
2016-04-28 3:06 ` [PATCH 2/2] revert: Btrfs: don't consider the missing device when allocating new chunks Anand Jain
2016-04-29 16:37 ` [PATCH 0/2] [RFC] btrfs: create degraded-RAID1 chunks David Sterba
2016-05-02 4:12 ` Anand Jain [this message]
2016-05-02 5:30 ` Duncan
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=5726D3AF.5010103@oracle.com \
--to=anand.jain@oracle.com \
--cc=clm@fb.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.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.