I rather randomly checked the status of my RAID arrays with cat/proc/mdstat and realized, that one of my arrays seems to be resyncing:

md1 : active raid1 sdb7[1] sdc7[0]
      238340224 blocks [2/2] [UU]
      [==========>..........]  resync = 52.2% (124602368/238340224) finish=75.0min speed=25258K/sec

Why is this and what does it mean? I seemingly can access the mount point just fine with r/w permissions.

EDIT 1 (in response to SLM's ANSWER)

I can't really see anything if I grep through dmesg and the --detail switch doesn't tell me much either, i.e. it displays that the resync is in progress... but no hint for the reason or why it might have gotten out of sync... - I guess I might just need to keep an eye on it before I start swapping out my hardware.


This would seem to be indicating that the syncing between the 2 members of the RAID are not staying in sync with each other.

1. Investigate logs

I'd investigate your dmesg logs and see if there are any messages stating that either of the physical HDDs that make up this array are having hardware failures.

2. Check mdadm

You can also consult mdadm using the --detail switch to find out more information about the resync like so:

$ sudo mdadm --detail /dev/md0
        Version : 00.90.03
  Creation Time : Sat Jan 26 09:14:11 2008
     Raid Level : raid1
     Array Size : 976759936 (931.51 GiB 1000.20 GB)
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Fri Jan  1 01:29:16 2010
          State : clean, resyncing
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

 Rebuild Status : 50% complete

           UUID : 37a3bfcb:41393031:23c133e6:3b879f08
         Events : 0.2178969

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1

If both devices seem fine and you cannot pinpoint which device is having an issue, you may want to temporarily run a diagnostic tool such as HDAT2 or SpinRite against each HDD to confirm their health.

3. Cabling

If the HDDs check out then I would start scrutinizing the cabling, I typically will swap these out.

4. Controller

I'd next scrutinize the controller itself, either taking the drives out of the affected system and diagnose them in a secondary system, or add a 3rd party controller card into the affected system to diagnose the issue further.

5. Power supply

Believe it or not, I've had issues in the past with HDDs and RAIDs where swapping out a failing, or about to fail, power supply, resolved my RAID health issues.

  • @cerr - yeah if the resyncs just keep happening at what appears to be random intervals then it's likely one of the HDDs is on the way out, or 3,4, or 5. The manifestation you're describing I've had happen a few times myself and it's been those situations which have resolved these failures, for me, in the past. – slm Sep 2 '14 at 3:17

Check your cron files, many distros do a scheduled resync/re-check once a week.

On CentOS 7.1 it's in /etc/cron.d/raid-check

# Run system wide raid-check once a week on Sunday at 1am by default
0 1 * * Sun root /usr/sbin/raid-check

To configure the behaviour edit /etc/sysconfig/raid-check

  • Although usually it's just a check, not a resync... – frostschutz Mar 2 '15 at 17:01
  • 2
    @frostschutz ... unless it's the first Sunday of a month: serverfault.com/a/255549/299551 In that case a resync is forced. – Dan Nov 6 '16 at 13:17

On Debian it is done from:


To disable:

chmod -x /usr/share/mdadm/checkarray

See also.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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