Odd disk slices - 11.23 on an rx7640

[Patrick Wallek]

A co-worker and I were assisting a customer in migrating an rx7640 running 11.23 with 5 vPars from one fibre switch to another.  Unfortunately there was only a single fibre path, so we had to shut down, migrate to the new switch and get all vPars booted on the new hardware.  That whole process went fine and we had no major issues.

The one odd thing we found was that on all of the vPars that booted from SAN, the boot LUNs are suddenly showing 7 slices on the boot disk rather than the normal 3.

For example:

From an ioscan on a vPar:

disk    101  1/0/8/1/0.210.5.239.0.0.1  sdisk    CLAIMED     DEVICE       DGC     CX3-40WDR5

/dev/dsk/c14t0d1     /dev/dsk/c14t0d1s4   /dev/rdsk/c14t0d1    /dev/rdsk/c14t0d1s4

/dev/dsk/c14t0d1s1   /dev/dsk/c14t0d1s5   /dev/rdsk/c14t0d1s1  /dev/rdsk/c14t0d1s5

/dev/dsk/c14t0d1s2   /dev/dsk/c14t0d1s6   /dev/rdsk/c14t0d1s2  /dev/rdsk/c14t0d1s6

/dev/dsk/c14t0d1s3   /dev/dsk/c14t0d1s7   /dev/rdsk/c14t0d1s3  /dev/rdsk/c14t0d1s7

However, when we had the server booted in nPar mode to determine the new hardware paths to boot the vPars from, the disk had the correct number of slices.

From an ioscan in nPar mode:

disk 579 1/0/8/1/0.210.5.239.0.0.1 sdisk CLAIMED DEVICE DGC CX3-40WDR5
/dev/dsk/c97t0d1 /dev/dsk/c97t0d1s3 /dev/rdsk/c97t0d1s2
/dev/dsk/c97t0d1s1 /dev/rdsk/c97t0d1 /dev/rdsk/c97t0d1s3
/dev/dsk/c97t0d1s2 /dev/rdsk/c97t0d1s1

The disk also showed the normal 3 slices BEFORE the move to the new fibre switch:

disk 1 1/0/8/1/0.20.25.239.0.0.1 sdisk CLAIMED DEVICE DGC CX3-40WDR5

/dev/dsk/c4t0d1 /dev/rdsk/c4t0d1
/dev/dsk/c4t0d1s1 /dev/rdsk/c4t0d1s1
/dev/dsk/c4t0d1s2 /dev/rdsk/c4t0d1s2
/dev/dsk/c4t0d1s3 /dev/rdsk/c4t0d1s3

The odd thing is that if you run an 'idisk -p' on the whole disk that is showing the 7 slices you only see:

# idisk -p /dev/rdsk/c14t0d1

idisk version: 1.32

EFI Primary Header:

        Signature                 = EFI PART

        Revision                  = 0x10000

        HeaderSize                = 0x5c

        HeaderCRC32               = 0xb83d558f

        MyLbaLo                   = 0x1

        MyLbaHi                   = 0x0

        AlternateLbaLo            = 0x77fffff

        AlternateLbaHi            = 0x0

        FirstUsableLbaLo          = 0x22

        FirstUsableLbaHi          = 0x0

        LastUsableLbaLo           = 0x77fffdc

        LastUsableLbaHi           = 0x0

        Disk GUID                 = 409b8e1a-990c-11de-8001-d6217b60e588

        PartitionEntryLbaLo       = 0x2

        PartitionEntryLbaHi       = 0x0

        NumberOfPartitionEntries  = 0xc

        SizeOfPartitionEntry      = 0x80

        PartitionEntryArrayCRC32  = 0xbcfb13e4

  Primary Partition Table (in 512 byte blocks):

    Partition 1 (EFI):

        Partition Type GUID       = c12a7328-f81f-11d2-ba4b-00a0c93ec93b

        Unique Partition GUID     = 409b8f96-990c-11de-8002-d6217b60e588

        Starting Lba Lo            = 0x22

        Starting Lba Hi            = 0x0

        Ending Lba Lo              = 0xfa021

        Ending Lba Hi              = 0x0

    Partition 2 (HP-UX):

        Partition Type GUID       = 75894c1e-3aeb-11d3-b7c1-7b03a0000000

        Unique Partition GUID     = 409b8fb4-990c-11de-8003-d6217b60e588

        Starting Lba Lo            = 0xfa022

        Starting Lba Hi            = 0x0

        Ending Lba Lo              = 0x7737821

        Ending Lba Hi              = 0x0

    Partition 3 (HPSP):

        Partition Type GUID       = e2a1e728-32e3-11d6-a682-7b03a0000000

        Unique Partition GUID     = 409b8fc8-990c-11de-8004-d6217b60e588

        Starting Lba Lo            = 0x7737822

        Starting Lba Hi            = 0x0

        Ending Lba Lo              = 0x77ff821

        Ending Lba Hi              = 0x0

So 'idisk' is only showing 3 slices on the disk but ioscan is seeing 7 slices.

Booting from the disk works fine and VG00 is fine using s2.

I am VERY VERY confused here.  Does anyone have ANY ideas?

[Patrick Wallek]

To add to the oddness...  The whole disk, and disk slices 1 - 3 are correct, but disk slices 4 - 7 are showing a size of '0 bytes'.

diskinfo /dev/rdsk/c14t0d1

SCSI describe of /dev/rdsk/c14t0d1:

             vendor: DGC

         product id: CX3-40WDR5

               type: direct access

               size: 62914560 Kbytes

   bytes per sector: 512

diskinfo /dev/rdsk/c14t0d1s1

SCSI describe of /dev/rdsk/c14t0d1s1:

             vendor: DGC

         product id: CX3-40WDR5

               type: direct access

               size: 512000 Kbytes

   bytes per sector: 512

diskinfo /dev/rdsk/c14t0d1s2

SCSI describe of /dev/rdsk/c14t0d1s2:

             vendor: DGC

         product id: CX3-40WDR5

               type: direct access

               size: 61991936 Kbytes

   bytes per sector: 512

diskinfo /dev/rdsk/c14t0d1s3

SCSI describe of /dev/rdsk/c14t0d1s3:

             vendor: DGC

         product id: CX3-40WDR5

               type: direct access

               size: 409600 Kbytes

   bytes per sector: 512

diskinfo /dev/rdsk/c14t0d1s4

SCSI describe of /dev/rdsk/c14t0d1s4:

             vendor: DGC

         product id: CX3-40WDR5

               type: direct access

               size: 0 Kbytes

   bytes per sector: 512

diskinfo /dev/rdsk/c14t0d1s5

SCSI describe of /dev/rdsk/c14t0d1s5:

             vendor: DGC

         product id: CX3-40WDR5

               type: direct access

               size: 0 Kbytes

   bytes per sector: 512

diskinfo /dev/rdsk/c14t0d1s6

SCSI describe of /dev/rdsk/c14t0d1s6:

             vendor: DGC

         product id: CX3-40WDR5

               type: direct access

               size: 0 Kbytes

   bytes per sector: 512

diskinfo /dev/rdsk/c14t0d1s7

SCSI describe of /dev/rdsk/c14t0d1s7:

             vendor: DGC

         product id: CX3-40WDR5

               type: direct access

               size: 0 Kbytes

   bytes per sector: 512

Is this somehow related to HP-UX, the vPar or the storage?

[Matti_Kurkela]

I think I saw this behavior once. Apparently the system is not actually detecting the number of slices on disk, but simply generating the device nodes for "enough" slices. The fact that slices 4-7 show zero size just indicates that they don't actually exist.

My memory is hazy, but... perhaps the system was in a LVM recovery mode or some other recovery mode when I saw this?

Apparently your nPar mode boot disk now has the correct FC device paths for vg00 in its LVM configuration, but the vPars might each need to have their vg00 re-imported while booting to LVM recovery mode.