Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.
share|improve this question
    
Did you check dmesg? –  frostschutz Nov 14 '13 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. –  Martin von Wittich Nov 14 '13 at 10:28
    
Curious which kernel and mdadm versions you have... –  derobert Nov 14 '13 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 –  Martin von Wittich Nov 14 '13 at 21:28
    
@derobert mdadm - v3.2.5 - 18th May 2012, from Debian wheezy –  Martin von Wittich Nov 14 '13 at 21:29

1 Answer 1

up vote 4 down vote accepted

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.

share|improve this answer
    
Hmm... would it then begin to sync directly after the first write, so that auto-read-only delays the sync? –  Martin von Wittich Nov 14 '13 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 '13 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. –  frostschutz Nov 14 '13 at 22:16

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.