On Thu, Apr 5, 2012 at 8:30 AM, Przemyslaw Czarnowski
<przemyslaw.hawrylewicz.czarnowski@xxxxxxxxx> 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@xxxxxxxxx>
> ---
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
