All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Tripathy <jonnyt@abpni.co.uk>
To: linux-raid@vger.kernel.org
Subject: Resync Every Sunday
Date: Sun, 01 Jul 2012 12:20:43 +0100	[thread overview]
Message-ID: <4FF0328B.5080103@abpni.co.uk> (raw)

Hi Everyone,

We have a few servers that use md raid with mdadm. Each server has 4 
arrays (md0,md1,md2,md3). md0,1,2 are small and md3 is very large. Every 
Sunday at 4:22am, the servers will start to resync. Here is some text 
from /var/log/messages for one of the servers:

Jul  1 04:22:01 server1 kernel: md: syncing RAID array md0
Jul  1 04:22:01 server1 kernel: md: minimum _guaranteed_ reconstruction 
speed: 1000 KB/sec/disc.
Jul  1 04:22:01 server1 kernel: md: using maximum available idle IO 
bandwidth (but not more than 200000 KB/sec) for reconstruction.
Jul  1 04:22:01 server1 kernel: md: using 128k window, over a total of 
104320 blocks.
Jul  1 04:22:01 server1 kernel: md: delaying resync of md2 until md0 has 
finished resync (they share one or more physical units)
Jul  1 04:22:01 server1 kernel: md: delaying resync of md3 until md0 has 
finished resync (they share one or more physical units)
Jul  1 04:22:05 server1 kernel: md: md0: sync done.
Jul  1 04:22:05 server1 kernel: md: delaying resync of md3 until md2 has 
finished resync (they share one or more physical units)
Jul  1 04:22:05 server1 kernel: md: delaying resync of md2 until md3 has 
finished resync (they share one or more physical units)
Jul  1 04:22:05 server1 kernel: md: syncing RAID array md3
Jul  1 04:22:05 server1 kernel: md: minimum _guaranteed_ reconstruction 
speed: 1000 KB/sec/disc.
Jul  1 04:22:05 server1 kernel: md: using maximum available idle IO 
bandwidth (but not more than 200000 KB/sec) for reconstruction.
Jul  1 04:22:05 server1 kernel: md: using 128k window, over a total of 
1888295936 blocks.

/proc/mdstat shows a progress bar for the array that is currently 
"re-syncing" (in the above case, md3). However, the disks in the servers 
seem fine, and it always seems to happen in the early hours of Sunday 
morning at 4:22am.

The issue gets further complicated as not all arrays are re-synced and I 
can seem to find a pattern as to what's selected. All I know is that at 
4:22, mdadm will "come alive" and attempt to do re-syncing of some (or 
all) of the arrays. On each of the servers, 3 of the arrays are small 
and one is large; this leads to the phenomenon that when we wake up on 
Sunday morning, a "random" selection of the servers will still be 
syncing (as mdadm has decided to "pick" the large md3 array to resync).

Here is output from /var/log/messages on a server that has only decided 
to re-sync 2 small arrays (md0 and md2):

Jul  1 04:22:01 server3 kernel: md: syncing RAID array md0
Jul  1 04:22:01 server3 kernel: md: minimum _guaranteed_ reconstruction 
speed: 1000 KB/sec/disc.
Jul  1 04:22:01 server3 kernel: md: using maximum available idle IO 
bandwidth (but not more than 200000 KB/sec) for reconstruction.
Jul  1 04:22:01 server3 kernel: md: using 128k window, over a total of 
104320 blocks.
Jul  1 04:22:01 server3 kernel: md: delaying resync of md2 until md0 has 
finished resync (they share one or more physical units)
Jul  1 04:22:02 server3 kernel: md: md0: sync done.
Jul  1 04:22:02 server3 kernel: md: syncing RAID array md2
Jul  1 04:22:02 server3 kernel: md: minimum _guaranteed_ reconstruction 
speed: 1000 KB/sec/disc.
Jul  1 04:22:02 server3 kernel: md: using maximum available idle IO 
bandwidth (but not more than 200000 KB/sec) for reconstruction.
Jul  1 04:22:02 server3 kernel: md: using 128k window, over a total of 
1052160 blocks.
Jul  1 04:22:15 server3 kernel: md: md2: sync done

What's going on? Am I missing something here? Is data on the arrays at 
risk? We're using CentOS 5 with mdadm v2.6.9. Kernel version is 
2.6.18-274.18.1.el5

Any help is appreciated.

Thanks

             reply	other threads:[~2012-07-01 11:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-01 11:20 Jonathan Tripathy [this message]
2012-07-01 12:04 ` Resync Every Sunday Jonathan Tripathy
2012-07-01 12:44   ` Mikael Abrahamsson
2012-07-01 12:53     ` Jonathan Tripathy
2012-07-01 20:41 ` Keith Keller
2012-07-01 20:44   ` Jonathan Tripathy
2012-07-01 21:24     ` Larkin Lowrey
2012-07-01 21:57       ` Jonathan Tripathy
2012-07-01 22:01         ` Jonathan Tripathy
2012-07-02 17:06           ` Larkin Lowrey
2012-07-02 21:30             ` Keith Keller
2012-07-02 22:55               ` Jonathan Tripathy
2012-07-03  3:33                 ` Keith Keller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FF0328B.5080103@abpni.co.uk \
    --to=jonnyt@abpni.co.uk \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.