Solaris Recreate Failed iSCSI Target Backed by Directory

• Updated March 17, 2019

After rebooting an Oracle Thumper 4500, the LUN information shown when running iscsitadm list target -v $TARGET was unknown and the Target name was truncated. The iSCSI initiator could connect to the iSCSI target but the disk would never mount. This particular Oracle server had not been patched in a while, and there was probably a patch available to fix this problem, but I wanted to describe the steps I took to recover the data.


For documentation purposes, the Oracle Thumber 4500 was at the following operating system and kernel version:

SunOS 5.10 Generic_139556-08 i86pc i386 i86pc Solaris 10 5/09 s10x_u7wos_08 X86

How the Failed iSCSI Target was Created

The failed iSCSI target was created using a directory as its backing store with the following commands:

zfs create pool1/iscsi

iscsitadm modify admin --base-directory /export/pool1/iscsi

iscsitadm create target --size 1T

iSCSI Target Before Reboot

Before rebooting the server, running iscsitadm list target -v displayed the following output:

    iSCSI Name:
    Alias: server
    Connections: 1
            iSCSI Name:
            Alias: unknown
    ACL list:
        Initiator: server
    TPGT list:
    LUN information:
        LUN: 0
            GUID: 600144f04cd2b7d40000144f20f16400
            VID: SUN
            PID: SOLARIS
            Type: disk
            Size: 1.0T
            Status: unknown

iSCSI Target After Reboot

After rebooting the server, running iscsitadm list target -v displayed the following output:

Target: server.matrix.examp
    iSCSI Name:
    Alias: server
    Connections: 0
    ACL list:
    TPGT list:
    LUN information:
        LUN: 0
            GUID: unknown
            VID: unknown
            PID: unknown
            Type: unknown
            Size: unknown
            Status: unknown

As mentioned, the Target name is truncated and all of the LUN information is unknown.


I was not sure if patching the server would fix the problem, and I was not able to patch the server at that time, so I decided to create another ZFS iSCSI target and copy the data bit-for-bit.

Create New ZFS Volume

zfs create -V 1T pool1/iscsi_server

Share the ZFS Volume Over iSCSI

zfs shareiscsi=on pool1/iscsi_server

Obtain the New ZFS Backing Store Location

iscsitadm list target -v pool1/iscsi_server | grep 'Backing store'

    # Output
    Backing store: /dev/zvol/rdsk/pool1/iscsi_server

Obtain the Old Directory Backing Store Location

Because the failed iSCSI target is not backed by a ZFS volume, the above step will not work to find the Backing store for the failed iSCSI target. The data for the failed iSCSI target is located in the Base Directory found using the command below. Change to that directory and follow the path until you find the lun.# file.

iscsitadm show admin

    # Output

Use dd to Copy All of the Data

The following command took about two days to finish:

dd if=/export/pool1/iscsi/ of=/dev/zvol/rdsk/pool1/iscsi_server bs=8k

After the command completed, I was able to mount the new ZFS iSCSI target and access the data.


If you found this post useful and would like to help support this site - and get something for yourself - sign up for any of the services listed below through the provided affiliate links. I will receive a referral payment from any of the services you sign-up for.

Get faster shipping and more with Amazon Prime: About to order something from Amazon but want to get more value out of the money you would normally pay for shipping? Sign-up for a free 30-day trial of Amazon Prime to get free two-day shipping, access to thousands of movies and TV shows, and more.

Thanks for reading and take care.