Re: [gentoo-user] Software RAID-1

[Kerin Millar]

On 26/08/2014 15:54, Peter Humphrey wrote:
> On Tuesday 26 August 2014 14:21:19 Kerin Millar wrote:
>> On 26/08/2014 10:38, Peter Humphrey wrote:
>>> On Monday 25 August 2014 18:46:23 Kerin Millar wrote:
>>>> On 25/08/2014 17:51, Peter Humphrey wrote:
>>>>> On Monday 25 August 2014 13:35:11 Kerin Millar wrote:
> --->8
>> Again, can you find out what the exit status is under the circumstances that
>> mdadm produces a blank error? I am hoping it is something other than 1.
>
> I've remerged mdadm to run this test. I'll report the result in a moment.
> [...] In fact it returned status 1. Sorry to disappoint :)

Thanks for testing. Can you tell me exactly what /etc/mdadm.conf 
contained at the time?

>
>>>>> Here's the position:
>>>>> 1.  I've left /etc/init.d/mdraid out of all run levels. I have nothing
>>>>> but comments in mdadm.conf, but then it's not likely to be read anyway
>>>>> if the init script isn't running.
>>>>> 2.  I have empty /etc/udev rules files as above.
>>>>> 3.  I have kernel auto-assembly of raid enabled.
>>>>> 4.  I don't use an init ram disk.
>>>>> 5.  The root partition is on /dev/md5 (0.99 metadata)
>>>>> 6.  All other partitions except /boot are under /dev/vg7 which is built
>>>>> on top of /dev/md7 (1.x metadata).
>>>>> 7.  The system boots normally.
>>>>
>>>> I must confess that this boggles my mind. Under these circumstances, I
>>>> cannot fathom how - or when - the 1.x arrays are being assembled.
>>>> Something has to be executing mdadm at some point.
>>>
>>> I think it's udev. I had a look at the rules, but I no grok. I do see
>>> references to mdadm though.
>> So would I, only you said in step 2 that you have "empty" rules, which I
>> take to mean that you had overridden the mdadm-provided udev rules with
>> empty files.
>
> Correct; that's what I did, but since removing mdadm I've also removed the
> corresponding, empty /etc/udev files.
>
> I don't think it's udev any more; I now think the kernel is cleverer than we
> gave it credit for (see below and attached dmesg).

Absolutely not ...

https://raid.wiki.kernel.org/index.php/RAID_superblock_formats#A_Note_about_kernel_autodetection_of_different_superblock_formats

https://github.com/torvalds/linux/blob/master/Documentation/md.txt

Both texts state unequivocally that kernel autodetection/assembly only 
works with the old superblock format.

Having read your dmesg.txt, I can only conclude that all of the arrays 
that the kernel is assembling are using the old superblock format, 
contrary to the information you have provided up until now. If so, then 
you do not rely on any of the three methods that I (correctly) said were 
necessary for 1.x superblock arrays.

To settle the matter, check the superblock versions using the method 
described below.

>
>> If all of the conditions you describe were true, you would have eliminated
>> all three of the aformentioned contexts in which mdadm can be invoked. Given
>> that mdadm is needed to assemble your 1.x arrays (see below), I would expect
>> such conditions to result in mount errors on account of the missing arrays.
> --->8
>> Again, 1.x arrays must be assembled in userspace. The kernel cannot
>> assemble them by itself as it can with 0.9x arrays. If you uninstall
>> mdadm, you will be removing the very userspace tool that is employed for
>> assembly. Neither udev nor mdraid will be able to execute it, which
>> cannot end well.
>
> I had done that, with no ill effect. I've just booted the box with no mdadm
> present. It seems the kernel can after all assemble the arrays (see attached
> dmesg.txt, edited). Or maybe I was wrong about the metadata and they're all
> 0.99. In course of checking this I tried a couple of things:
>
> # lvm pvck /dev/md7
>    Found label on /dev/md7, sector 1, type=LVM2 001
>    Found text metadata area: offset=4096, size=1044480
> # lvm vgdisplay
>    --- Volume group ---
>    VG Name               vg7
>    System ID
>    Format                lvm2
>    Metadata Areas        1
>    Metadata Sequence No  14
>    VG Access             read/write
>    VG Status             resizable
>    MAX LV                0
>    Cur LV                13
>    Open LV               13
>    Max PV                0
>    Cur PV                1
>    Act PV                1
>    VG Size               500.00 GiB
>    PE Size               4.00 MiB
>    Total PE              127999
>    Alloc PE / Size       108800 / 425.00 GiB
>    Free  PE / Size       19199 / 75.00 GiB
>    VG UUID               ll8OHc-if2H-DVTf-AxrQ-5EW0-FOLM-Z73y0z
>
> Can you tell from that which metadata version I used when I created vg7? It
> looks like 1.x to me, since man lvm refers to formats (=metadata types) lvm1
> and lvm2 - or am I reading too much into that?

LVM has nothing to do with md. I did allude to this in my first response 
on the thread. The above output demonstrates that you have designated an 
md block device as a PV (LVM physical volume). Any block device can be a 
PV - LVM does not care.

When I talk about 1.x metadata, I am talking about the md superblock. 
You can find out what the metadata format is like so:-

# mdadm --detail /dev/md7 | grep Version

To be clear, LVM does not enter into it.

>
> See here what the postinst message said when I remerged sys-fs/mdadm-3.3.1-r2
> for the return-code test you asked for:
>
>   * If you're not relying on kernel auto-detect of your RAID
>   * devices, you need to add 'mdraid' to your 'boot' runlevel:
>   *      rc-update add mdraid boot
>
> Could be thought ambiguous.

I would go so far as to say it is false, but this is a distinct matter.

>
> Is nobody else experiencing this behaviour?
>

--Kerin