RAID5 ne pas spindown après la croissance (ext4lazyinit)

J'ai eu une matrice RAID5 composée de disques 3x5To assemblés en utilisant mdadm. En plus de cela, j'ai créé un LUKS/dmcrypt couche de cryptage et formaté le périphérique crypté avec ext4. Je veux que les disques s'arrêtent en cas d'inactivité.

Tout a bien fonctionné pendant plusieurs mois, les disques se sont éteints après une minute d'inactivité. Maintenant, j’ai ajouté à la baie de disques un quatrième disque de 5 To du même type: sudo mdadm --add /dev/md0 /dev/sdb1, puis j'ai développé le tableau sur ce disque ( mdadm --grow /dev/md0 --raid-devices=4 ), et a finalement développé le système de fichiers avec sudo fsck -f /dev/mapper/raid5 et sudo resize2fs /dev/mapper/raid5.

Aucune erreur ne s'est produite et le tableau a maintenant une taille supérieure de 5 To. Mais les disques ne tournent plus. La machine fonctionne 24 heures sur 24, 7 jours sur 7, n'utilise pas les disques, mais malgré quelques jours d'attente, les disques fonctionnent tout le temps.

iotop montre des occurrences fréquentes de ext4lazyinit, qui apparaît moins d’une seconde toutes les quelques secondes. Je n'avais pas remarqué cela avant de développer le système de fichiers. Alors, probablement, est-ce que ces tâches permettent de garder les disques éveillés? Mais comment puis-je forcer ext4lazyinit pour compléter sa tâche?

ext4lazyinit fait exactement ce qui est dit - il initialise le reste du système de fichiers de manière paresseuse. Il fait cela pour donner l’apparence de produire rapidement un système de fichiers. Comme vous l'avez remarqué, cela va essayer d'influencer le moins possible les performances de votre système, ce qui signifie que cela prendra beaucoup de temps.

La première option est d'attendre, cela finira par s'arrêter et vos disques devraient revenir au repos.

Une autre option consiste à démonter le système de fichiers et à le monter temporairement avec -o init_itable=0, obligeant l'init paresseux à être plus proactif, mais les performances en souffriront. La valeur par défaut est 10, donc si les performances sont importantes entre-temps,  Peut-être essayer des valeurs entre les deux. ( ref )

init_itable=n    The lazy itable init code will wait n times the number of milliseconds
                 it took to zero out the previous block group's inode table. This
                 minimizes the impact on the system performance while file system's
                 inode table is being initialized.

Une troisième option est de désactiver l’initialisation itable - bien qu’à mon avis, c’est une mauvaise option, en particulier pour un système de fichiers en production qui contient probablement des données importantes (c’est pourquoi vous utilisez un RAID, non?)

Vous pouvez le faire avec le noinit_itable option:

noinit_itable     Do not initialize any uninitialized inode table blocks in the
                  background. This feature may be used by installation CD's so that the
                  install process can complete as quickly as possible; the inode table 
                  initialization process would then be deferred until the next time the
                  file system is unmounted.

Edit: Estimations sur la durée.

N'oubliez pas que les disques ont des performances d'écriture de ~ 110-120 Mo / s ... Vous utilisez un tableau, donc dans un monde idéal, l'amélioration passera à ~ 330-360 Mo / s ( 110 * (n - 1) ). J'ai aussi vu RAID5 fonctionner beaucoup plus lent (~ 40 Mo / s sur 8 disques avec un contrôleur RAID - douloureux).

Avec une vitesse estimée à 110 Mo / s, vous disposez d'environ 12 heures pour une init. Complète de 5 To.