31

I've created a new md array with the following command:

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

But now /proc/mdstat shows the array as "auto-read-only" with 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>

According to this site I can fix this with:

mdadm --readwrite /dev/md1

And that does work:

~ # 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>

But I still would like to know what is going on here, and I can't find any real information about that. Does anyone know why the array defaults to this state?

EDIT: added dmesg output:

~ # 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.
5
  • Did you check dmesg? Nov 14, 2013 at 0:16
  • @frostschutz I've added the dmesg lines that were logged to the syslog yesterday, time zone UTC+1 (I've rebooted the machine since so I no longer have access to the original dmesg). Nothing out of the ordinary as far as I can tell. Nov 14, 2013 at 10:28
  • Curious which kernel and mdadm versions you have...
    – derobert
    Nov 14, 2013 at 17:35
  • @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 Nov 14, 2013 at 21:28
  • @derobert mdadm - v3.2.5 - 18th May 2012, from Debian wheezy Nov 14, 2013 at 21:29

1 Answer 1

39

When an array is initially assembled, it is placed in "auto-read-only" mode. I quickly tested, with my kernel (3.10.x) and mdadm (3.3), this doesn't happen on create—but you must be running different versions.

However, auto-read-only isn't an error, nor is it anything to worry about. The basic idea behind it is to make --assemble (and, apparently now, even --create) safer: Nothing is written to the disks until the array goes read-write. (I'm not sure if maybe the metadata is still written on create.)

The array will automatically switch from auto-read-only to read-write when it receives its first write. So, if you went ahead and created a filesystem on the device, or a LVM physical volume, or whatever, it would have switched to read-write, and started the sync.

The only reason you'd need to run mdadm --readwrite on it is if you want it to sync before you perform any writes.

3
  • Hmm... would it then begin to sync directly after the first write, so that auto-read-only delays the sync? Nov 14, 2013 at 21:31
  • @MartinvonWittich Yes, it'd start syncing right after the first write. So yes, it delays it—typically by a few seconds, as you'd normally do something (pvcreate, mkfs, etc.) with a new array pretty soon after --create.
    – derobert
    Nov 14, 2013 at 21:51
  • "you must be running different versions" is a guess? I'm using the latest versions and can't remember this behaviour for any older version. Unless @MartinvonWittich did something he didn't tell us about (like reboot after create), that doesn't explain what happened at all. Nov 14, 2013 at 22:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .