Re: raid1 degraded mount still produce single chunks, writeable mount not allowed

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2017-03-03 00:56, Kai Krakow wrote:
> Am Thu, 2 Mar 2017 11:37:53 +0100
> schrieb Adam Borowski <kilobyte@angband.pl>:
>
>> On Wed, Mar 01, 2017 at 05:30:37PM -0700, Chris Murphy wrote:
>>> [1717713.408675] BTRFS warning (device dm-8): missing devices (1)
>>> exceeds the limit (0), writeable mount is not allowed
>>> [1717713.446453] BTRFS error (device dm-8): open_ctree failed
>>>
>>> [chris@f25s ~]$ uname -r
>>> 4.9.8-200.fc25.x86_64
>>>
>>> I thought this was fixed. I'm still getting a one time degraded rw
>>> mount, after that it's no longer allowed, which really doesn't make
>>> any sense because those single chunks are on the drive I'm trying to
>>> mount.
>>
>> Well, there's Qu's patch at:
>> https://www.spinics.net/lists/linux-btrfs/msg47283.html
>> but it doesn't apply cleanly nor is easy to rebase to current kernels.
>>
>>> I don't understand what problem this proscription is trying to
>>> avoid. If it's OK to mount rw,degraded once, then it's OK to allow
>>> it twice. If it's not OK twice, it's not OK once.
>>
>> Well, yeah.  The current check is naive and wrong.  It does have a
>> purpose, just fails in this, very common, case.
>
> I guess the reasoning behind this is: Creating any more chunks on this
> drive will make raid1 chunks with only one copy. Adding another drive
> later will not replay the copies without user interaction. Is that true?
>
> If yes, this may leave you with a mixed case of having a raid1 drive
> with some chunks not mirrored and some mirrored. When the other drives
> goes missing later, you are loosing data or even the whole filesystem
> although you were left with the (wrong) imagination of having a
> mirrored drive setup...
>
> Is this how it works?
>
> If yes, a real patch would also need to replay the missing copies after
> adding a new drive.
>
The problem is that that would use some serious disk bandwidth without 
user intervention.  The way from userspace to fix this is to scrub the 
FS.  It would essentially be the same from kernel space, which means 
that if you had a multi-TB FS and this happened, you'd be running at 
below capacity in terms of bandwidth for quite some time.  If this were 
to be implemented, it would have to be keyed off of the per-chunk 
degraded check (so that _only_ the chunks that need it get touched), and 
there would need to be a switch to disable it.