linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Williams, Dan J" <dan.j.williams@intel.com>
To: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com>
Cc: neilb@suse.de, linux-raid@vger.kernel.org, ed.ciechanowski@intel.com
Subject: Re: [PATCH 3/4] imsm: avoid double change of serial number of missing device
Date: Thu, 5 Apr 2012 10:41:28 -0700	[thread overview]
Message-ID: <CABE8wwtXAJa9de0CS9OqNUbR5rG3bLth0HP4jYG+M_sMu_FE6A@mail.gmail.com> (raw)
In-Reply-To: <20120405153054.19851.39398.stgit@linux.site>

On Thu, Apr 5, 2012 at 8:30 AM, Przemyslaw Czarnowski
<przemyslaw.hawrylewicz.czarnowski@intel.com> wrote:
> If degraded state is set in OROM, it do not set 'failed' flag for missing,
> device, just changes serial number, sets scsiId to 0xffff and sets highest
> bit in ord table in map. When mdadm replaces missing disk, the one left
> there is marked as failed and missing again (changing already marked serial
> number).
>
> Signed-off-by: Przemyslaw Czarnowski <przemyslaw.hawrylewicz.czarnowski@intel.com>
> ---
>  super-intel.c |   15 +++++++++------
>  1 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/super-intel.c b/super-intel.c
> index f843997..b361b72 100644
> --- a/super-intel.c
> +++ b/super-intel.c
> @@ -6908,12 +6908,15 @@ static int mark_failure(struct imsm_dev *dev, struct imsm_disk *disk, int idx)
>        if (is_failed(disk) && (ord & IMSM_ORD_REBUILD))
>                return 0;
>
> -       memcpy(buf, disk->serial, MAX_RAID_SERIAL_LEN);
> -       buf[MAX_RAID_SERIAL_LEN] = '\000';
> -       strcat(buf, ":0");
> -       if ((len = strlen(buf)) >= MAX_RAID_SERIAL_LEN)
> -               shift = len - MAX_RAID_SERIAL_LEN + 1;
> -       strncpy((char *)disk->serial, &buf[shift], MAX_RAID_SERIAL_LEN);
> +       /* do not add ":0", OROM has already done it */
> +       if (!(ord & IMSM_ORD_REBUILD)) {

What about the case where we are rebuilding to this disk and then get
a failure, doesn't this prevent the serial number from getting
updated?

The metadata expectation, as far as I can tell, is in-metadata-serial
!= serial-retrieved-from-disk.  So if it gets mutated twice what harm
does that cause?

> +               memcpy(buf, disk->serial, MAX_RAID_SERIAL_LEN);
> +               buf[MAX_RAID_SERIAL_LEN] = '\000';
> +               strcat(buf, ":0");
> +               if ((len = strlen(buf)) >= MAX_RAID_SERIAL_LEN)
> +                       shift = len - MAX_RAID_SERIAL_LEN + 1;
> +               strncpy((char *)disk->serial, &buf[shift], MAX_RAID_SERIAL_LEN);
> +       }
>
>        disk->status |= FAILED_DISK;
>        set_imsm_ord_tbl_ent(map, slot, idx | IMSM_ORD_REBUILD);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2012-04-05 17:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-05 15:28 [PATCH 0/4] Imsm OROM compatibility/boot support fixes Przemyslaw Czarnowski
2012-04-05 15:29 ` [PATCH 1/4] imsm: monitor: do not finish migration if there are no failed disks Przemyslaw Czarnowski
2012-04-05 17:56   ` Williams, Dan J
2012-04-05 15:30 ` [PATCH 2/4] imsm: clean up missing disks if there are any left after migration Przemyslaw Czarnowski
2012-04-05 17:06   ` Williams, Dan J
2012-04-05 15:30 ` [PATCH 3/4] imsm: avoid double change of serial number of missing device Przemyslaw Czarnowski
2012-04-05 17:41   ` Williams, Dan J [this message]
2012-04-05 15:31 ` [PATCH 4/4] imsm: monitor: do not finish recovery, when raid goes to read-only Przemyslaw Czarnowski
2012-04-05 17:37   ` Williams, Dan J
2012-04-09 23:22 ` [PATCH 0/4] Imsm OROM compatibility/boot support fixes 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=CABE8wwtXAJa9de0CS9OqNUbR5rG3bLth0HP4jYG+M_sMu_FE6A@mail.gmail.com \
    --to=dan.j.williams@intel.com \
    --cc=ed.ciechanowski@intel.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=przemyslaw.hawrylewicz.czarnowski@intel.com \
    /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).