iscsi target shows up with multiple partitions - why?

Question

We've been using CentOS 7 for a couple of years now to serve up iSCSI targets to our TigerStore metadata server on our SAN. We've used the same procedure to create the targets, detailed below. I just brought two new arrays online following this procedure and we're seeing something super weird: The first partition of each of the arrays appears in Windows as if it was a single drive with 4 partitions (each array has 4 partitions on the Linux side, but each of those should show up as its own separate iSCSI target). The remaining three partitions are picked up as separate iSCSI targets by the Windows iSCSI initiator, and Windows Disk Management sees them as separate. But the first always shows up as if it was one drive with 4 partitions. The procedure we use is as follows:

1. Create RAID 6 in hardware RAID controller
2. Open each array in gparted and create GPT partition table; create partitions as Primary Partition/Unformatted; Commit changes
3. reboot
4. in targetcli, create a block for each partition using /dev/disk/by-partuuid/ for each partition as the unique identifier
5. in targetcli, create target, pointing to that backstore.

This is a truncated example of what we see in targetcli. (resolve-3 is the first partition on the array, thus the one that's appearing to windows as having 4 partitions. phx-1 is the second partition on that same array, and it appears as its own target, and as a partition inside the target that should be just resolve-3:

/> ls
o- / ......................................................................................................................... [...]
o- backstores .............................................................................................................. [...]
| o- block ................................................................................................. [Storage Objects: 16] 
| | o- phx-1 ......................... [/dev/disk/by-partuuid/9672e724-10bb-4559-91cb-321a3778bb14 (0 bytes) write-thru activated]
| | | o- alua ................................................................................................... [ALUA Groups: 1]
  | | |   o- default_tg_pt_gp ....................................................................... [ALUA state: Active/optimized]
| | o- resolve-3 ..................... [/dev/disk/by-partuuid/4be97a07-ad47-4c7a-9ee1-d4630e3c3eb7 (0 bytes) write-thru activated]
| | | o- alua ................................................................................................... [ALUA Groups: 1]
  | | |   o- default_tg_pt_gp ....................................................................... [ALUA state: Active/optimized]
| o- fileio ................................................................................................. [Storage Objects: 0]
| o- pscsi .................................................................................................. [Storage Objects: 0]
| o- ramdisk ................................................................................................ [Storage Objects: 0]
o- iscsi ........................................................................................................... [Targets: 16]
| o- iqn.2019-09.com.our-domain-name-here:phx-1 ............................................................................. [TPGs: 1]
| | o- tpg1 .................................................................................................. [gen-acls, no-auth]
| |  o- acls .......................................................................................................... [ACLs: 0]
| |  o- luns .......................................................................................................... [LUNs: 1]
| |  | o- lun0 .................... [block/phx-1 (/dev/disk/by-partuuid/9672e724-10bb-4559-91cb-321a3778bb14) (default_tg_pt_gp)]
| |  o- portals .................................................................................................... [Portals: 1]
| |  o- 10.0.0.1:3260 .................................................................................................... [OK]
| o- iqn.2019-09.com.our-domain-name-here:resolve-3 ......................................................................... [TPGs: 1]
| | o- tpg1 .................................................................................................. [gen-acls, no-auth]
| |  o- acls .......................................................................................................... [ACLs: 0]
| |  o- luns .......................................................................................................... [LUNs: 1]
| |  | o- lun0 ................ [block/resolve-3 (/dev/disk/by-partuuid/4be97a07-ad47-4c7a-9ee1-d4630e3c3eb7) (default_tg_pt_gp)]
| |  o- portals .................................................................................................... [Portals: 1]
| |  o- 10.0.0.1:3260 .................................................................................................... [OK]
 o- loopback ......................................................................................................... [Targets: 0]
o- srpt ............................................................................................................. [Targets: 0]

And this is what Windows sees when the targets are mounted: Disk 13 is 'phx-1'. Disk 15 should be 'resolve-3' and the size of the first partition it contains is correct for that. The second partition in Disk 15 is 'phx-1'. The two 5.5T partitions also appear as their own drives and inside of resolve-3. (the similar looking Disks 14 and 16 are the other array)

I really have no idea what's happening here. The parameters in targetcli are identical to those of the other arrays we're serving up as iSCSI targets, which are working perfectly normally. I've tried wiping out all the partitions, backstores and targets, and rebuilding them from scratch, even with different IQNs in case Windows was caching something. Any thoughts?

Answer 1

So the issue seems to be that gparted wasn't showing old partitions. I was creating the new partitions by using "Unformatted" as the format type, but that seems to leave old cruft behind. I created a new partition that was the entire 54TB volume, using "cleared" as the format type, then deleted that and re-created the partitions using unformatted. lo and behold, the phantom partitions are gone and it seems to work now.