Re: raid1: cannot add disk to replace faulty because can only mount fs as read-only.

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

On 2017-01-28 04:17, Andrei Borzenkov wrote:
> 27.01.2017 23:03, Austin S. Hemmelgarn пишет:
>> On 2017-01-27 11:47, Hans Deragon wrote:
>>> On 2017-01-24 14:48, Adam Borowski wrote:
>>>
>>>> On Tue, Jan 24, 2017 at 01:57:24PM -0500, Hans Deragon wrote:
>>>>
>>>>> If I remove 'ro' from the option, I cannot get the filesystem mounted
>>>>> because of the following error: BTRFS: missing devices(1) exceeds the
>>>>> limit(0), writeable mount is not allowed So I am stuck. I can only
>>>>> mount the filesystem as read-only, which prevents me to add a disk.
>>>>
>>>> A known problem: you get only one shot at fixing the filesystem, but
>>>> that's
>>>> not because of some damage but because the check whether the fs is in a
>>>> shape is good enough to mount is oversimplistic.
>>>>
>>>> Here's a patch, if you apply it and recompile, you'll be able to mount
>>>> degraded rw.
>>>>
>>>> Note that it removes a safety harness: here, the harness got tangled
>>>> up and
>>>> keeps you from recovering when it shouldn't, but it _has_ valid uses
>>>> that.
>>>>
>>>> Meow!
>>>
>>> Greetings,
>>>
>>> Ok, that solution will solve my problem in the short run, i.e. getting
>>> my raid1 up again.
>>>
>>> However, as a user, I am seeking for an easy, no maintenance raid
>>> solution.  I wish that if a drive fails, the btrfs filesystem still
>>> mounts rw and leaves the OS running, but warns the user of the failing
>>> disk and easily allow the addition of a new drive to reintroduce
>>> redundancy.  Are there any plans within the btrfs community to implement
>>> such a feature?  In a year from now, when the other drive will fail,
>>> will I hit again this problem, i.e. my OS failing to start, booting into
>>> a terminal, and cannot reintroduce a new drive without recompiling the
>>> kernel?
>> Before I make any suggestions regarding this, I should point out that
>> mounting read-write when a device is missing is what caused this issue
>> in the first place.
>
>
> How do you replace device when filesystem is mounted read-only?
>
I'm saying that the use case you're asking to have supported is the 
reason stuff like this happens.  If you're mounting read-write degraded 
and fixing the filesystem _immediately_ then it's not an issue, that's 
exactly what read-write degraded mounts are for.  If you're mounting 
read-write degraded and then having the system run as if nothing was 
wrong, then I have zero sympathy because that's _dangerous_, even with 
LVM, MD-RAID, or even hardware RAID (actually, especially with hardware 
RAID, LVM and MD are smart enough to automatically re-sync, most 
hardware RAID controllers aren't).

That said, as I mentioned further down in my initial reply, you 
absolutely should be monitoring the filesystem and not letting things 
get this bad if at all possible.  It's actually very rare that a storage 
device fails catastrophically with no warning (at least, on the scale 
that most end users are operating).  At a minimum, even if you're using 
ext4 on top of LVM, you should be monitoring SMART attributes on the 
storage devices (or whatever the SCSI equivalent is if you use 
SCSI/SAS/FC devices).  While not 100% reliable (they are getting better 
though), they're generally a pretty good way to tell if a disk is likely 
to fail in the near future.