Re: RAID1 assembly requires manual "mdadm --run"

[Molle Bestefich <molle.bestefich@gmail.com>]

Tyler wrote:
> Molle Bestefich wrote:
>> Neil Brown wrote:
>>> Molle Bestefich wrote:
>>>> Mitchell Laks wrote:
>>>>> However I think that raids should boot as long as they are
intact, as a matter
>>>>> of policy. Otherwise we lose our  ability to rely upon them for remote
>>>>> servers...
>>>>>
>>>>>
>>>> It does seem wrong that a RAID 5 starts OK with a disk missing, but a
>>>> RAID 1 fails.
>>>>
>>>> Perhaps MD is unable to tell which disk in the RAID 1 is the freshest
>>>> and therefore refuses to assemble any RAID 1's with disks missing?
>>>>
>>>>
>>> This doesn't sound right at all.
>>>
>>> "--run" is required to start a degraded array as a way of confirming
>>> to mdadm that you really have listed all the drives available.
>>> The normal way of starting an array at boot time is by describing the
>>> array (usually by UUID) in mdadm.conf and letting mdadm find the
>>> component devices with "mdadm --assemble --scan".
>>>
>>> This usage does not require --run.
>>>
>>> The only time there is a real reluctance to start a degraded array is
>>> when it is raid5/6 and it suffered an unclean shutdown.
>>> A dirty, degraded raid5/6 can have undetectably data corruption, and I
>>> really want you to be aware of that and not just assume that "because
>>> it started, the data must be OK".
>>>
>>>
>>
>> Sounds very sane.
>>
>> So a clean RAID1 with a disk missing should start without --run, just
>> like a clean RAID5 with a disk missing?
>>
>> Nevermind, I'll try to reproduce it instead of asking too many questions.
>> And I suck a bit at testing MD with loop devices, so if someone could
>> pitch in and tell me what I'm doing wrong here, I'd appreciate it very
>> much (-:
>>
>> # mknod /dev/md0 b 9 0
>> # dd if=/dev/zero of=test1 bs=1M count=100
>> # dd if=/dev/zero of=test2 bs=1M count=100
>> # dd if=/dev/zero of=test3 bs=1M count=100
>> # losetup /dev/loop1 test1
>> # losetup /dev/loop2 test2
>> # losetup /dev/loop3 test3
>> # mdadm --create /dev/md0 -l 1 -n 3 /dev/loop1 /dev/loop2 /dev/loop3
>> mdadm: array /dev/md0 started.
>>
>> # mdadm --detail --scan > /etc/mdadm.conf
>> # cat /etc/mdadm.conf
>> ARRAY /dev/md0 level=raid1 num-devices=3
>>    UUID=1dcc972f:0b856580:05c66483:e14940d8
>>    devices=/dev/loop/1,/dev/loop/2,/dev/loop/3
>>
>>
> Why does this show /dev/loop/1 instead of /dev/loop1 ?

Hm!  Didn't spot that.
This machine is using udev, so /dev/loopx is a symbolic link to /dev/loop/x.
I haven't got a clue why DM resolves the link..

But since mdadm --assemble --scan doesn't seem to work correctly using
this example, and I'm punching in loop device names anyway, it's less
important..

>> # mdadm --stop /dev/md0
>> # mdadm --assemble --scan
>> mdadm: no devices found for /dev/md0
>>
>> // ^^^^^^^^^^^^^^^^^^^^^^^^  ??? Why?
>>
>> # mdadm --assemble /dev/md0 /dev/loop1 /dev/loop2 /dev/loop3
>> mdadm: /dev/md0 has been started with 3 drives.
>>
>> // So far so good..
>>
>> # mdadm --stop /dev/md0
>> # losetup -d /dev/loop3
>> # mdadm --assemble /dev/md0 /dev/loop1 /dev/loop2 /dev/loop3
>> mdadm: no RAID superblock on /dev/loop7
>> mdadm: /dev/loop7 has no superblock - assembly aborted
>>
>>
> Where's loop7 coming from all of a sudden? I thought you were using
> loop1, loop2, loop3

Ehehe.. Oops.
I redid the test with different loop devices, just to be sure.

Copy/pasted from the wrong place in the terminal window.
Sorry for the confusion.  Just imagine that the 7 is really a 3 :-).

>> // ^^^^^^^^^^^^^^^^^^^^^^^^  ??? It aborts :-(...
>> // Doesn't an inactive loop device seem the same as a missing disk to MD?
>>
>> # rm -f /dev/loop3
>> # mdadm --assemble /dev/md0 /dev/loop1 /dev/loop2 /dev/loop3
>> mdadm: cannot open device /dev/loop7: No such file or directory
>> mdadm: /dev/loop7 has no superblock - assembly aborted
>>
>>
> Once again, where is loop7 coming from?

Same as above.