Re: problems with lots of arrays

[Hannes Reinecke <hare@suse.de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/12/2016 03:55 AM, NeilBrown wrote:
> On Wed, May 11 2016, Shaohua Li wrote:
> 
>> On Wed, May 11, 2016 at 08:39:53AM +1000, NeilBrown wrote:
>>> 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.
>> 
>> I'm wondering why udev open the device with major/minor without
>> checking if the device exists. A simple 'stat' check is neat.
> 
> A big part of the role of udev is to create the device nodes in
> /dev.
> 
Not any more.
devtmpfs will create the device nodes automagically,
no need for udev to interfere.

Cheers,

Hannes
- -- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJXNBttAAoJEGz4yi9OyKjPAHcP/R4+cgYjqcNH4acdGLIR9g4x
ASIieuAEe1E4/OkWcSM1pRkOMHy8fjlXw41EKBePZRshkDAL0avoPkwL6QuCbK6T
jktuTHogNKgplGyBn9ibwKBSeXlw3skDHpYU+BoIoNGJD0fGGUcFHgJQj48ptsny
mpuqyy/1LXFQCYI7Sv96cZg1InA60I6vKEJXUud78InE01bJZWS6eHCh4PH9yq9S
7l+yrnMbtMiz78TtYvgSF77CVIFgJkV8xtWO3AExTDHL1V5UtLXnAI+tS4xOtvsE
vA0NTOpiVplwJVaLEwlgRFaAZYs8zFpiko/TUitQmx7BgaxPVas30h7R0uoWhsQY
ejn6HVSQMvKJQWl0guD1JnU8CrPge36OdJnqDtLOY9Dqwqun97EriGWle8j8zpgo
yJG852IchaMYB/YPhZvag4+hDRVgqVZO4XWyC9j5pk/tPBMwFPMMk7gZSDjDKMHD
Rm11uu1O6itUJr/IDMX5broTAI6e+DJDOUn4imXjSUmTp+cWqq+HSuvQR1/Amg6S
QuOSTJbOeEF+bEM209IMmCQj6pG/Fhw2vODGrnptiFI+g5Rsf6v8/DbOnSxJhnVX
QolSvjMigykY/K7JqvjYBjtCMrwvrEgNHOAUTOD9F70SWatetLA2rAbrl71LHMgS
CByHeGYD9xkd/UzzLKy0
=4WAN
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html