Re: RAID1 storage server won't boot with one disk missing

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

[-- Attachment #1: Type: text/plain, Size: 3340 bytes --]

On 2015-09-17 16:18, Chris Murphy wrote:
> On Thu, Sep 17, 2015 at 1:02 PM, Roman Mamedov <rm@romanrm.net> wrote:
>> On Thu, 17 Sep 2015 19:00:08 +0200
>> Goffredo Baroncelli <kreijack@libero.it> wrote:
>>
>>> On 2015-09-17 17:18, Anand Jain wrote:
>>>>   it looks like -o degraded is going to be a very obvious feature,
>>>>   I have plans of making it a default feature, and provide -o
>>>>   nodegraded feature instead. Thanks for comments if any.
>>>>
>>> I am not sure if there is a "good" default for this kind of problem
>>
>> Yes there is. It is whatever people came to expect from using other RAID
>> systems and/or generally expect from RAID as a concept.
>>
>> Both mdadm software RAID, and I believe virtually any hardware RAID controller
>> out there will let you to successfully boot up and give read-write(!) access
>> to a RAID in a non-critical failure state, because that's kind of the whole
>> point of a RAID, to eliminate downtime. If the removed disk is later re-added,
>> then it is automatically resynced. Mdadm can also make use of its 'write
>> intent bitmap' to resync only those areas of the array which were in any way
>> touched during the absence of the newly re-added disk.
>>
>> If you're concerned that the user "misses" the fact that they have a disk
>> down, then solve *that*, make some sort of a notify daemon, e.g. mdadm has a
>> built-in "monitor" mode which sends E-Mail on critical events with any of the
>> arrays.
>
> Given the current state: no proposal and no work done yet, I think
> it's premature to change the default.
>
> It's an open question what a modern monitoring and notification
> mechanism should look like. At the moment it'd be a unique Btrfs thing
> because the mdadm and LVM methods aren't abstracted enough to reuse. I
> wonder if the storaged and/or openlmi folks have some input on what
> this would look like. Feedback from KDE and GNOME also, who rely on at
> least mdadm in order to present user space notifications. I think
> udisks2 is on the way out and storaged is on the way in, there's just
> too much stuff that udisks2 doesn't do and is getting confused about,
> including LVM thinly provisioned volumes, not just Btrfs stuff.
>
>
The problem with that is that storaged (from what I understand) is 
systemd dependent, and there are too many people out there who don't 
want systemd.  udisks2 will almost certainly live on (just like 
consolekit has).  And if it's something systemd integrated, I can 
already tell you it will look like the OS X solution.  Now, what I think 
it should look like is a different story, I'd say that:
1. It should give the option to either:
     a. Refuse to boot degraded.
     b. Ask the operator if he wants to boot degraded
     c. Just automatically boot degraded, and probably send a 
notification about it.
2. Provide some service (sadly probably dbus based) to schedule 
scrub/balance/re-sync operations and get info about ENOSPC/sync 
failure/parity mismatch/device failure/SMART status failure.
3. Provide a consistent interface to such operations on hardware RAID 
controllers that support them.
4. Provide the ability to notify via arbitrary means on any of the above 
mentioned issues.
5. Have the ability to turn anything not needed off on a given system.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3019 bytes --]