linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@arcor.de>
To: Francis Moreau <francis.moro@gmail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: MD array keeps resyncing after rebooting
Date: Thu, 25 Jul 2013 20:58:19 +0200	[thread overview]
Message-ID: <51F1754B.5000905@arcor.de> (raw)
In-Reply-To: <CAC9WiBjQz6MJxBuw+cLWFZ-vOsdbYYSKdE575emH_AG5EmnGdw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3010 bytes --]

On 07/24/2013 03:50 PM, Francis Moreau wrote:

> I regenerated the initramfs in order to use the new binaries when
> booting and now I can see some new warnings:
> 
>   $ dracut -f
>   mdmon: Failed to load secondary DDF header on /dev/block/8:0
>   mdmon: Failed to load secondary DDF header on /dev/block/8:16
>   ...
> 
> I ignored them for now.

The message is non-fatal. But is certainly strange, given that you have
a LSI BIOS. It looks as if something was wrong with your secondary
header. You may try the attached patch to understand the problem better.

> Now the latest version of mdadm is used :
> 
>   $ cat /proc/mdstat
>   Personalities : [raid1]
>   md126 : active raid1 sdb[1] sda[0]
>         975585280 blocks super external:/md127/0 [2/2] [UU]
> 
>   md127 : inactive sdb[1](S) sda[0](S)
>         2354608 blocks super external:ddf

So you did another rebuild of the array with the updated mdadm?

> I run mdadm -E /dev/sdX for all RAID disks before and after reboot.
> I'm still having this warning:
> 
>    mdmon: Failed to load secondary DDF header on /dev/sda
> 
> You can find the differences below:
> 
> diff -Nurp before/sda.txt after/sda.txt
> --- before/sda.txt      2013-07-24 15:15:33.304015379 +0200
> +++ after/sda.txt       2013-07-24 15:49:09.520132838 +0200
> @@ -9,11 +9,11 @@ Controller GUID : 4C534920:20202020:FFFF
>    Redundant hdr : yes
>    Virtual Disks : 1
> 
> -      VD GUID[0] : 4C534920:20202020:80861D60:00000000:3F2103E0:00001450
> -                  (LSI      07/24/13 12:18:08)
> +      VD GUID[0] : 4C534920:20202020:80861D60:00000000:3F213401:00001450
> +                  (LSI      07/24/13 15:43:29)

This is weird. it looks as if the array had been recreated by the BIOS.
Normally the GUID should stay constant over reboots.

>           unit[0] : 0
>          state[0] : Optimal, Not Consistent
> -   init state[0] : Fully Initialised

Not Consistent and Fully Initialized - This looks as if the array didn't
close down cleanly. Is this the result of rebuilding the array with
mdmon 3.3-rc1?

Thinking about it - you did some coding of your own to start mdmon in
the initrd, right? Do you also make sure that mdadm -Ss is called after
umounting the file systems, but before shutdown? If not, an inconsistent
state might result.

> +   init state[0] : Not Initialised
>         access[0] : Read/Write
>           Name[0] : array0
>   Raid Devices[0] : 2 (0 1)
> diff -Nurp before/sdb.txt after/sdb.txt
> --- before/sdb.txt      2013-07-24 15:17:50.300581049 +0200
> +++ after/sdb.txt       2013-07-24 15:49:15.159997204 +0200
> @@ -9,11 +9,11 @@ Controller GUID : 4C534920:20202020:FFFF
>    Redundant hdr : yes
>    Virtual Disks : 1
> 
> -      VD GUID[0] : 4C534920:20202020:80861D60:00000000:3F2103E0:00001450
> -                  (LSI      07/24/13 12:18:08)
> +      VD GUID[0] : 4C534920:20202020:80861D60:00000000:3F213401:00001450
> +                  (LSI      07/24/13 15:43:29)

Again, new GUID. Did you recreate the array?

Regards
Martin


[-- Attachment #2: load-ddf-header-logging.patch --]
[-- Type: text/x-patch, Size: 1410 bytes --]

From 4e689b7d63e21db21f5bbc0e06b011648265705d Mon Sep 17 00:00:00 2001
From: Martin Wilck <mwilck@arcor.de>
Date: Thu, 25 Jul 2013 21:48:32 +0200
Subject: [PATCH] DDF: load_ddf_header: more error logging

Try to determine problem if load_ddf_header fails.
---
 super-ddf.c |   12 +++++++++---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/super-ddf.c b/super-ddf.c
index 234d816..fdfc1d5 100644
--- a/super-ddf.c
+++ b/super-ddf.c
@@ -754,18 +754,24 @@ static int load_ddf_header(int fd, unsigned long long lba,
 	if (read(fd, hdr, 512) != 512)
 		return 0;
 
-	if (!be32_eq(hdr->magic, DDF_HEADER_MAGIC))
+	if (!be32_eq(hdr->magic, DDF_HEADER_MAGIC)) {
+		pr_err("%s: bad header magic\n", __func__);
 		return 0;
-	if (!be32_eq(calc_crc(hdr, 512), hdr->crc))
+	}
+	if (!be32_eq(calc_crc(hdr, 512), hdr->crc)) {
+		pr_err("%s: bad CRC\n", __func__);
 		return 0;
+	}
 	if (memcmp(anchor->guid, hdr->guid, DDF_GUID_LEN) != 0 ||
 	    memcmp(anchor->revision, hdr->revision, 8) != 0 ||
 	    !be64_eq(anchor->primary_lba, hdr->primary_lba) ||
 	    !be64_eq(anchor->secondary_lba, hdr->secondary_lba) ||
 	    hdr->type != type ||
 	    memcmp(anchor->pad2, hdr->pad2, 512 -
-		   offsetof(struct ddf_header, pad2)) != 0)
+		   offsetof(struct ddf_header, pad2)) != 0) {
+		pr_err("%s: header mismatch\n", __func__);
 		return 0;
+	}
 
 	/* Looks good enough to me... */
 	return 1;
-- 
1.7.1


  reply	other threads:[~2013-07-25 18:58 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-23  9:46 MD array keeps resyncing after rebooting Francis Moreau
2013-07-23 12:55 ` Francis Moreau
2013-07-23 18:52   ` Martin Wilck
2013-07-23 18:52     ` Martin Wilck
2013-07-23 20:01       ` Francis Moreau
2013-07-23 21:21         ` Martin Wilck
2013-07-24  4:32           ` Francis Moreau
2013-07-24 13:50             ` Francis Moreau
2013-07-25 18:58               ` Martin Wilck [this message]
2013-07-25 19:06                 ` Martin Wilck
2013-07-25 20:23                   ` Francis Moreau
2013-07-29 15:46                     ` Francis Moreau
2013-07-25 20:21                 ` Francis Moreau
2013-07-31 19:36                 ` Francis Moreau
2013-08-01 13:28                   ` Francis Moreau
2013-08-01 18:15                   ` Martin Wilck
2013-08-02 12:49                     ` Francis Moreau
     [not found]                     ` <CAC9WiBhGyE=OJdSeL_OsPxtirhJ2=3WRsk=uBPiOTzMjBCf-dA@mail.gmail.com>
2013-08-02 18:19                       ` Martin Wilck
2013-08-03  0:08                         ` Sam Bingner
2013-08-03 11:02                         ` Francis Moreau
2013-08-08  7:18                         ` Francis Moreau
2013-08-24 18:54                           ` Martin Wilck
2013-08-26  7:44                             ` Francis Moreau
2013-08-31 19:23                             ` Francis Moreau
2013-09-01 17:05                               ` Martin Wilck
2013-08-05  6:08                     ` NeilBrown

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=51F1754B.5000905@arcor.de \
    --to=mwilck@arcor.de \
    --cc=francis.moro@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).