Okay, that makes sense. The problem was that the new partition table was not available, because it was in use when I modified it. :P Kind of my problem I suppose. lol
On Tue, Nov 6, 2012 at 11:03 PM, Mike Christie <[email protected]> wrote: > On 11/06/2012 09:47 PM, Trenton Adams wrote: > > Hi Guys, > > > > I ran into something interesting, and I'm wondering if this can or > > should be fixed. > > > > I setup a second disk pointing to a partition on my drive, which already > > had another partition shared out using open-iscsi. I found out really > > quickly that no drives show up in Windows 7 computer management console, > > even though it's successful connecting. > > > > So, I ran tgtadm -m target -o show, and got the following... > > Target 2: iqn.2012-11.ca.trentonadams:tdadesktop > > System information: > > Driver: iscsi > > State: ready > > I_T nexus information: > > I_T nexus: 1 > > Initiator: iqn.1991-05.com.microsoft:tda-desktop > > Connection: 1 > > IP Address: 192.168.8.4 > > LUN information: > > LUN: 0 > > Type: controller > > SCSI ID: IET 00020000 > > SCSI SN: beaf20 > > Size: 0 MB, Block size: 1 > > Online: Yes > > Removable media: No > > Prevent removal: No > > Readonly: No > > Backing store type: null > > Backing store path: None > > Backing store flags: > > Account information: > > iqn.1991-05.com.microsoft:tda-desktop > > ACL information: > > 192.168.8.191 > > 192.168.8.99 > > 192.168.8.4 > > 127.0.0.1 > > > > > > Luckily, I thought about what the problem might be, seeing the first > > partition was working fine. The problem that occurred was that I had > > edited the disk partition table while tgtd was using the drive. Of > > course you get the standard message that a reboot is necessary. Instead > > of that, I shut down tgtd, opened the disk, and re-wrote the partition > > table. After restarting tgtd, the output of the above command is now... > > > > Target 2: iqn.2012-11.ca.trentonadams:tdadesktop > > System information: > > Driver: iscsi > > State: ready > > I_T nexus information: > > LUN information: > > LUN: 0 > > Type: controller > > SCSI ID: IET 00020000 > > SCSI SN: beaf20 > > Size: 0 MB, Block size: 1 > > Online: Yes > > Removable media: No > > Prevent removal: No > > Readonly: No > > Backing store type: null > > Backing store path: None > > Backing store flags: > > LUN: 1 > > Type: disk > > SCSI ID: IET 00020001 > > SCSI SN: beaf21 > > Size: 268436 MB, Block size: 512 > > Online: Yes > > Removable media: No > > Prevent removal: No > > Readonly: No > > Backing store type: rdwr > > Backing store path: /dev/sdf2 > > Backing store flags: > > Account information: > > iqn.1991-05.com.microsoft:tda-desktop > > ACL information: > > 192.168.8.191 > > 192.168.8.99 > > 192.168.8.4 > > 127.0.0.1 > > > > So, I guess my question is, should this be considered a "bug"? Is there > > any way that open-iscsi can notify the client that the disk is not yet > > working? > > > > I am not sure if I understand the problem. In the case where lun1 is not > made you want open-iscsi to return some sort of error or notification? > If so, there is nothing open-iscsi can do. We just log into the target > and ask it what luns it has. open-iscsi does not even do the part where > it asks what luns are available. It has the scsi layer do this. > > In the iscsi spec there is a way for the target to tell the initiator > that new luns have been added but tgtd does not support it. You would > have to ask the developers on tgt list to implement it. > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
