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
next prev parent 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).