Re: problems with lots of arrays

[NeilBrown <neilb@suse.de>]

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

On Wed, May 11 2016, Jes Sorensen wrote:

> Mike Lovell <mike.lovell@endurance.com> writes:
>> we have a number of systems that have a large number of software
>> arrays running. its in the couple hundred range. we have been using a
>> custom built kernel based on 3.4 but are wanting to update to a
>> mainline kernel and have been experimenting with 4.4. the systems are
>> running recent centos 6 releases but we have been downgrading the
>> mdadm version from 3.3.2 in 6.7 to a custom build 3.2.6. we installed
>> the downgraded version due to a problem with array numbering. i
>> emailed the list a while ago explaining the issue and submitting a
>> patch to fix [1]. i never heard anything back and since we had a
>> simple fix i didn't follow up on it.
>
> [snip]
>
>> what do you all think?
>>
>> thanks
>> mike
>>
>> [1] http://marc.info/?l=linux-raid&m=142387809409798&w=2
>
> Staying consistent in using dev_t rather than casting back and forth to
> int seems a reasonable fix to apply to mdadm. It obviously won't change
> the issues with the newer kernels, but I don't see any reason why we
> shouldn't apply that fix to mdadm.
>
> Neil any thoughts on this?

I agree that changing "int" to "dev_t" is a good idea.

We should really fix the more general problem too.

On any kernel with  /sys/module/md_mod/parameters/new_array
find_free_devnm avoid trying anything above 511. (1<<9)-1.

If that fails to find a free number, then it should probably try a name
like "md_NN" and act as though ci->name is set.

Also, when a "name" given for the md array that is longer than 28 bytes
we need to fall back to choose an array name ourselves even if ci->name
is set.  Start with md_512 and work upwards.
Rather than probing we should read /sys/block looking for "md_*" and
maybe choose 1 more than the largest number found.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]