Bug 748986 - mdadm starts resync on imsm raid even in Normal state
mdadm starts resync on imsm raid even in Normal state
Product: Fedora
Classification: Fedora
Component: mdadm (Show other bugs)
i686 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Jes Sorensen
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2011-10-25 14:57 EDT by Peter Bieringer
Modified: 2012-07-11 03:31 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 753335 (view as bug list)
Last Closed: 2012-07-11 03:31:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Peter Bieringer 2011-10-25 14:57:48 EDT
Description of problem:
mdadm starts resync on imsm raid even BIOS reports "Normal" state (this state was the result of a successful sync until last poweroff.

Version-Release number of selected component (if applicable):

(initramfs created using shown mdadm version)

How reproducible:

Steps to Reproduce:
1. boot
2. let resync finish
3. poweroff
4. poweron
Actual results:
Resync starts again

Expected results:

# cat /proc/mdstat 
Personalities : [raid1] 
md127 : active raid1 sda[1] sdb[0]
      156288000 blocks super external:/md0/0 [2/2] [UU]
      [>....................]  resync =  4.9% (7779584/156288132) finish=64.6min speed=38294K/sec
md0 : inactive sdb[1](S) sda[0](S)
      5544 blocks super external:imsm

Additional info:

related dmesg report:

[    3.311658] dracut: Autoassembling MD Raid
[    3.324529] md: md0 stopped.
[    3.326070] md: bind<sda>
[    3.326143] md: bind<sdb>
[    3.326280] dracut: mdadm: Container /dev/md0 has been assembled with 2 drives
[    3.334575] md: md127 stopped.
[    3.334724] md: bind<sdb>
[    3.337308] md: bind<sda>
[    3.341079] md: raid1 personality registered for level 1
[    3.343813] bio: create slab <bio-1> at 1
[    3.346517] md/raid1:md127: not clean -- starting background reconstruction
[    3.349168] md/raid1:md127: active with 2 out of 2 mirrors
[    3.351725] md127: detected capacity change from 0 to 160038912000
[    3.355530]  md127: p1 p2 p3 p4 < p5 p6 p7 p8 >
[    3.482773] md: md127 switched to read-write mode.
[    3.485360] md: resync of RAID array md127
[    3.487793] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
[    3.490229] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for resync.
[    3.492691] md: using 128k window, over a total of 156288132k.
[    3.496305] dracut: mdadm: Started /dev/md127 with 2 devices

Is there any debug information available how to get more information why mdadm is detecting that md127 is not clean while this was reported as "Normal" in the BIOS?
Comment 1 Jes Sorensen 2011-10-26 07:08:57 EDT
Does this happen both if you are using the RAID for booting from and/or
if you have the RAID as a secondary device and boot off a regular partition?
Comment 2 Peter Bieringer 2011-10-26 14:48:03 EDT
The RAID is my primary device, I can't easily configure it as second device...no other bootable disks in there.

But it looks like it has to do with the shutdown procedure.

Yesterday, I need to poweroff via Alt-Sysrq (hanging during "unmount", probably related to autofs problem). Now booting today (BIOS-Status: Normal), no resync was triggered. Rebooting now again will result in resync (array detected as "not clean").

My system is too fast to follow last messages before booting, but I thought I have seen on Alt-Sysrq-Poweroff something like "raid status stored", while on reboot, nothing such was seen.
Comment 3 Jes Sorensen 2011-10-26 15:11:05 EDT
Interesting - I was wondering if it was related to shutdown. The problem with
BIOS RAID is that the kernel cannot do the full shutdown on it's own, so if
something is hanging and preventing mdadm/mdmon from doing their job, it could
result in some of the RAID metadata not being written out as it should.
Comment 4 Peter Bieringer 2011-10-26 15:53:33 EDT
So, next normal shutdown triggered and power-on again -> resync starts again.

For me it looks like only Alt-Sysrq-Poweroff will leave a synced RAID in proper state for next power-on.

Normal power-off or reboot won't. Any suggestions for debugging this deeper?
Comment 5 Jeff Gustafson 2011-12-06 20:59:25 EST
I am also having this issue on Fedora 16. The system was running Fedora 15 and was upgraded to 16. Something happen in Fedora 15 that was causing it to not boot correctly. I went ahead and upgraded to 16. It went smooth except for this issue.
Comment 6 Jes Sorensen 2012-07-11 03:31:48 EDT
Fedora 15 has reached end of life, so we'll continue to investigate this
problem in the Fedora 17 bugzilla #753335

Note You need to log in before you can comment on or make changes to this bug.