Hi Robin,

 

thanks, that’s exactly the case.

I asked the customer to pull the disks again and wait a minute before reinserting and the disks are now displayed correctly.

 

Best,

 

Alexander Griesser

Head of Systems Operations

 

ANEXIA Internetdienstleistungs GmbH

 

E-Mail: AGriesser@anexia-it.com

Web: http://www.anexia-it.com

 

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt

Geschäftsführer: Alexander Windbichler

Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601

 

Von: Robin Mesotten <robin@mesotten.eu>
Gesendet: Donnerstag, 29. Oktober 2020 02:59
An: Alexander Griesser <AGriesser@anexia-it.com>
Betreff: Re: Wrong disk bay reported

 

Hi Alexander,

I have seen this a few time in the lab when moving disks from one slot to another. Is it possible your customer first inserted the disks in to slot 22 and 23 then afterwards realised they started on the wrong side and moved them?

I also found this bug 1246444.

 Moving disks within a system without following the appropriate procedure
 can cause the same disk name to be reported for multiple physical disk
 locations. This might cause the management gateway process to crash or
 generate other unpredictable system behavior. When moving storage disks,
 you must wait at least 20 seconds after removal before inserting the disk
 in the new location.
 
 
 
To recover from this issue, choose one of the following options:
   1. Perform a takeover and giveback of the affected systems.
   2. Remove the disk for at least 20 seconds, and then reinsert it.
      Note: If the disk is part of an aggregate, this option will result
      in a degraded RAID group and disk reconstruction will be initiated.
 
Regards,
Robin
 
 

On 28/10/2020 22:45, Alexander Griesser wrote:

Hey,

 

did anyone ever encounter such a mismatch?

Customer reported that they installed new disks in slots 0 and 1, but this is what I can see here:

 

CLUSTER::*> disk show -container-type unassigned

                     Usable           Disk    Container   Container

Disk                   Size Shelf Bay Type    Type        Name      Owner

---------------- ---------- ----- --- ------- ----------- --------- --------

1.11.22                   -    11  22 SAS     unassigned  -         -

1.11.23                   -    11  23 SAS     unassigned  -         -

2 entries were displayed.

 

Whereas:

 

CLUSTER::*> node run -node node1 disk show -n

  DISK       OWNER                    POOL   SERIAL NUMBER         HOME                    DR HOME

------------ -------------            -----  -------------         -------------           -------------

0b.11.1      Not Owned                  NONE   50M0A02MF4XR

0b.11.0      Not Owned                  NONE   50M0A01XF4XR

 

And also:

 

CLUSTER::*> node run -node node1 sasadmin shelf

 

Expanders on channel 0a:

     +-----------------------------------------------------------------------+

   0 | 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|10|11|12|13|14|15|16|17|18|19|20|21|22|23|

     +-----------------------------------------------------------------------+

 

     +-----------------------------------------------------------------------+

  11 | 0| 1|DD|DD|DD|DD|DD|DD|DD|DD|DD|DD|DD|DD|DD|DD|DD|DD|DD|DD|DD|DD|DD|DD|

     +-----------------------------------------------------------------------+

 

The system is running on an older Ontap release (9.2P2).

Is there any command to „rescan“ the disk locations?

 

Best,

 

Alexander Griesser

Head of Systems Operations

 

ANEXIA Internetdienstleistungs GmbH

 

E-Mail: AGriesser@anexia-it.com

Web: http://www.anexia-it.com

 

Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt

Geschäftsführer: Alexander Windbichler

Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601