Le nouveau tableau md est en lecture seule et a resync = PENDING

17

J'ai créé un nouveau tableau md avec la commande suivante:

mdadm --create /dev/md1 -l 1 -n 2 /dev/sd[ed]1

Mais /proc/mdstatmontre maintenant le tableau comme "lecture seule automatique" avec resync = PENDING:

~ # cat /proc/mdstat 
Personalities : [raid1] 
md1 : active (auto-read-only) raid1 sde1[1] sdd1[0]
      976630336 blocks super 1.2 [2/2] [UU]
        resync=PENDING

md0 : active raid1 sdb1[0] sdc1[1]
      1953511936 blocks [2/2] [UU]

unused devices: <none>

Selon ce site, je peux résoudre ce problème avec:

mdadm --readwrite /dev/md1

Et cela fonctionne:

~ # mdadm --readwrite /dev/md1
~ # cat /proc/mdstat 
Personalities : [raid1] 
md1 : active raid1 sde1[1] sdd1[0]
      976630336 blocks super 1.2 [2/2] [UU]
      [>....................]  resync =  0.0% (54400/976630336) finish=598.2min speed=27200K/sec

md0 : active raid1 sdb1[0] sdc1[1]
      1953511936 blocks [2/2] [UU]

unused devices: <none>

Mais je voudrais quand même savoir ce qui se passe ici, et je ne trouve aucune information réelle à ce sujet. Est-ce que quelqu'un sait pourquoi le tableau est par défaut à cet état?

EDIT: sortie dmesg ajoutée:

~ # grep kernel /var/log/syslog.1 
Nov 13 10:03:44 iserv kernel: [160446.860113] e1000: eth1 NIC Link is Down
Nov 13 10:04:48 iserv kernel: [160511.017666] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
Nov 13 20:12:40 iserv kernel: [196982.775186]  sda: sda1
Nov 13 20:12:59 iserv kernel: [197001.598187]  sdd: sdd1
Nov 13 20:13:13 iserv kernel: [197016.344939]  sde: sde1
Nov 13 20:14:05 iserv kernel: [197067.520825] md: bind<sdd1>
Nov 13 20:14:05 iserv kernel: [197067.521263] md: bind<sde1>
Nov 13 20:14:05 iserv kernel: [197067.670215] md/raid1:md1: not clean -- starting background reconstruction
Nov 13 20:14:05 iserv kernel: [197067.670219] md/raid1:md1: active with 2 out of 2 mirrors
Nov 13 20:14:05 iserv kernel: [197067.670246] md1: detected capacity change from 0 to 1000069464064
Nov 13 20:14:05 iserv kernel: [197067.675101]  md1: unknown partition table
Nov 13 20:24:10 iserv kernel: [197672.572128] md: md1 switched to read-write mode.
Nov 13 20:24:10 iserv kernel: [197672.572269] md: resync of RAID array md1
Nov 13 20:24:10 iserv kernel: [197672.572273] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
Nov 13 20:24:10 iserv kernel: [197672.572275] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for resync.
Nov 13 20:24:10 iserv kernel: [197672.572280] md: using 128k window, over a total of 976630336k.
Martin von Wittich
la source
Avez-vous vérifié dmesg?
frostschutz
@frostschutz J'ai ajouté les lignes dmesg qui ont été enregistrées hier dans le syslog, fuseau horaire UTC + 1 (j'ai redémarré la machine depuis donc je n'ai plus accès au dmesg d'origine). Pour autant que je sache, rien d'extraordinaire.
Martin von Wittich
Curieux de savoir quelles versions de noyau et de mdadm vous avez ...
derobert
@derobert Linux hostname 3.10-0.bpo.3-686-pae # 1 SMP Debian 3.10.11-1 ~ bpo70 + 1 (2013-09-24) i686 GNU / Linux
Martin von Wittich
@derobert mdadm - v3.2.5 - 18 mai 2012, de Debian wheezy
Martin von Wittich

Réponses:

25

Lorsqu'un tableau est initialement assemblé, il est placé en mode "lecture seule". J'ai rapidement testé, avec mon noyau (3.10.x) et mdadm (3.3), cela ne se produit pas lors de la création, mais vous devez exécuter différentes versions.

Cependant, la lecture seule n'est pas une erreur, ni une inquiétude. L'idée de base derrière cela est de rendre --assemble(et, apparemment maintenant, même --create) plus sûr: rien n'est écrit sur les disques jusqu'à ce que le tableau passe en lecture-écriture. (Je ne sais pas si les métadonnées sont peut-être encore écrites lors de la création.)

La baie passera automatiquement de la lecture seule à la lecture-écriture lorsqu'elle recevra sa première écriture. Donc, si vous aviez continué et créé un système de fichiers sur l'appareil, ou un volume physique LVM, ou autre, il aurait basculé en lecture-écriture et démarré la synchronisation.

La seule raison pour laquelle vous devez l'exécuter mdadm --readwriteest si vous souhaitez qu'il se synchronise avant d'effectuer des écritures.

derobert
la source
Hmm ... commencerait-il alors à se synchroniser directement après la première écriture, de sorte que la lecture automatique retarde la synchronisation?
Martin von Wittich
@MartinvonWittich Oui, la synchronisation commencerait immédiatement après la première écriture. Alors oui, elle retarde-il généralement de quelques secondes, comme vous le feriez normalement faire quelque chose ( pvcreate, mkfs, etc.) avec un nouveau tableau assez peu de temps après --create.
derobert
"vous devez exécuter différentes versions" est une supposition? J'utilise les dernières versions et je ne me souviens de ce comportement pour aucune ancienne version. À moins que @MartinvonWittich n'ait fait quelque chose dont il ne nous a pas parlé (comme le redémarrage après la création), cela n'explique pas du tout ce qui s'est passé.
frostschutz