udev mapping revisited - getting /dev/iscsi/$TargetName from udev
Robin H. Johnson
devices or symlinks out of udev, that contain the TargetName in their
filename.
The /dev/disk/by-id/* tree isn't suitable for my purposes, I've got far
too many targets to have a TargetName->$ID_SERIAL mapping that's built
up manually (since iscsiadm doesn't have $ID_SERIAL that we can query).
Going back to linux-iscsi, there was a file in /sys that contained the
TargetName, but it doesn't exist anymore with open-iscsi (There used to
be a TargetAlias file as well).
Was there a specific reason it was removed?
Can it be brought back?
Ultimately all I want is a symlink residing at /dev/iscsi/$TargetName,
pointing to which device is actually in use.
--
Robin Hugh Johnson
E-Mail : rob...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Mike Christie
> Ok, udev has brought up here before, but I'm looking for a way to get
> devices or symlinks out of udev, that contain the TargetName in their
> filename.
>
> The /dev/disk/by-id/* tree isn't suitable for my purposes, I've got far
> too many targets to have a TargetName->$ID_SERIAL mapping that's built
> up manually (since iscsiadm doesn't have $ID_SERIAL that we can query).
I am not sure I understand what you are doing though. Normally does udev do:
/dev/disk/by-id/some-uuid-from-scsi_id
but what is the comment about building up something manually about or I
guess I am also asking what is $ID_SERIAL? Are you going to do
/dev/disk/$TargetNames/disks-for-that-target
or
/dev/disk/$TargetNames-some-uuid-from-scsi_id
>
> Going back to linux-iscsi, there was a file in /sys that contained the
> TargetName, but it doesn't exist anymore with open-iscsi (There used to
> be a TargetAlias file as well).
>
> Was there a specific reason it was removed?
linux-iscsi had it becuase it did the login in kernel. It just became a
nice thing to have for debugging to also export it via sysfs. I mean
since we had the string in the kernel it was a couple lines to export in
sysfs. For open-iscsi since it does the login in userspace the
targetname was never in the kernel so to save memory I never added it.
> Can it be brought back?
Hannes has code to do this. For HW iscsi we will probably have to do
this too so I am fine with this I guess.
>
> Ultimately all I want is a symlink residing at /dev/iscsi/$TargetName,
> pointing to which device is actually in use.
>
I did not parse this which may be why I did not understand your other
comments.
Robin H. Johnson
> I am not sure I understand what you are doing though. Normally does udev do:
>
> /dev/disk/by-id/some-uuid-from-scsi_id
# scsi_id -x -a -s /block/sdc -g
ID_VENDOR=EQLOGIC
ID_MODEL=100E-00
ID_REVISION=2.2
ID_SERIAL=30690a0180042864b8a3184010000b032
ID_TYPE=disk
ID_BUS=scsi
> but what is the comment about building up something manually about or I
> guess I am also asking what is $ID_SERIAL? Are you going to do
> /dev/disk/$TargetNames/disks-for-that-target
> or
> /dev/disk/$TargetNames-some-uuid-from-scsi_id
I'd like /dev/iscsi/iqn.2001-05.com.equallogic:6-8a0900-4b8642001-32b000000184318a-test1
Because the only way I have to get $ID_SERIAL for my targets is:
1. take snapshot of /dev/disks/by-id/
2. login to target
3. take snapshot of /dev/disks/by-id/
4. compare output of #1 and #2 to find $ID_SERIAL
5. Save $ID_SERIAL gained in #4 with TargetName in DB somewhere.
> >Was there a specific reason it was removed?
> linux-iscsi had it becuase it did the login in kernel. It just became a
> nice thing to have for debugging to also export it via sysfs. I mean
> since we had the string in the kernel it was a couple lines to export in
> sysfs. For open-iscsi since it does the login in userspace the
> targetname was never in the kernel so to save memory I never added it.
Makes sense.
> >Can it be brought back?
> Hannes has code to do this. For HW iscsi we will probably have to do
> this too so I am fine with this I guess.
Hannes: Could you maybe post an early patch to be tested/beaten on?
> >Ultimately all I want is a symlink residing at /dev/iscsi/$TargetName,
> >pointing to which device is actually in use.
> I did not parse this which may be why I did not understand your other
> comments.
udev creates symlinks named /dev/disks/by-id/scsi-$ID_SERIAL pointing
to /dev/sdX. The EqualLogic target does NOT provide $ID_SERIAL anywhere
in it's CLI interface that I've been able to find, so the only
information I have is the TargetName.
Given only the TargetName (as listed in the iscsiadm output) and not
the $ID_SERIAL, I want a symlink that connects me to correct /dev/sdX
device.
Patrick Mansfield
> Given only the TargetName (as listed in the iscsiadm output) and not
> the $ID_SERIAL, I want a symlink that connects me to correct /dev/sdX
> device.
So, why not add a udev rule using iscsiadm output?
Though I still don't fully understand why you want the target name,
besides wanting to use/group the devices based on target name.
-- Patrick Mansfield
Mike Christie
> On Tue, Feb 07, 2006 at 11:39:35PM -0600, Mike Christie wrote:
>
>>I am not sure I understand what you are doing though. Normally does udev do:
>>
>>/dev/disk/by-id/some-uuid-from-scsi_id
>
> $ID_SERIAL is the serial number variable from scsi_id.
>
> # scsi_id -x -a -s /block/sdc -g
> ID_VENDOR=EQLOGIC
> ID_MODEL=100E-00
> ID_REVISION=2.2
> ID_SERIAL=30690a0180042864b8a3184010000b032
> ID_TYPE=disk
> ID_BUS=scsi
>
>
>>but what is the comment about building up something manually about or I
>>guess I am also asking what is $ID_SERIAL? Are you going to do
>>/dev/disk/$TargetNames/disks-for-that-target
>>or
>>/dev/disk/$TargetNames-some-uuid-from-scsi_id
>
> I'd like /dev/iscsi/iqn.2001-05.com.equallogic:6-8a0900-4b8642001-32b000000184318a-test1
>
> Because the only way I have to get $ID_SERIAL for my targets is:
Does equalogic targets do a single lun per target? So if you do
"iscsiadm -m node", do you get
[5ef5eb] 192.168.77.51:3260,0
iqn.2001-05.com.equallogic:6-8a0900-725fe0101-4fbff112427436a2-test-2
an entry like this for earch LUN (the serial or name after the ":" is
different for each one though)?
Robin H. Johnson
> Does equalogic targets do a single lun per target? So if you do
> "iscsiadm -m node", do you get
> [5ef5eb] 192.168.77.51:3260,0
> iqn.2001-05.com.equallogic:6-8a0900-725fe0101-4fbff112427436a2-test-2
> an entry like this for earch LUN (the serial or name after the ":" is
> different for each one though)?
Robin H. Johnson
> On Tue, Feb 07, 2006 at 10:07:35PM -0800, Robin H. Johnson wrote:
> > Given only the TargetName (as listed in the iscsiadm output) and not
> > the $ID_SERIAL, I want a symlink that connects me to correct /dev/sdX
> > device.
> So, why not add a udev rule using iscsiadm output?
accomplishes this while only matching iSCSI entries.
The tough part in writing a rule is finding the mapping between the
iscsiadm -m session output, and the sysfs tree. So far it LOOKS like
the $SID value from the session output matches up with the host number,
but I don't know how reliable that is.
I had another idea for doing it, that I'm working on still - iscsi_id in
the fashion of the other *_id binaries from the udev tree, but using
hacked up iscsiadm sources to accomplish the objective.
However this has the downside of requiring iscsid to be up and running
for the queries to work :-(.
Mike Christie
> On Tue, Feb 07, 2006 at 10:29:42PM -0800, Patrick Mansfield wrote:
>
>>On Tue, Feb 07, 2006 at 10:07:35PM -0800, Robin H. Johnson wrote:
>>
>>>Given only the TargetName (as listed in the iscsiadm output) and not
>>>the $ID_SERIAL, I want a symlink that connects me to correct /dev/sdX
>>>device.
>>
>>So, why not add a udev rule using iscsiadm output?
>
> I haven't been able to come up with any rule that successfully
> accomplishes this while only matching iSCSI entries.
>
> The tough part in writing a rule is finding the mapping between the
> iscsiadm -m session output, and the sysfs tree. So far it LOOKS like
> the $SID value from the session output matches up with the host number,
> but I don't know how reliable that is.
it is reliable for software iscsi. if you end up using something like
qla4xxx then it will not match up.
Robin H. Johnson
> >The tough part in writing a rule is finding the mapping between the
> >iscsiadm -m session output, and the sysfs tree. So far it LOOKS like
> >the $SID value from the session output matches up with the host number,
> >but I don't know how reliable that is.
> it is reliable for software iscsi. if you end up using something like
> qla4xxx then it will not match up.
iscsiadm to find Target we're going to be SOL. I'd guess the qla4xxx
hardware will require having a TargetName sysfs node in the scsi_host
location, which we can then utilize correctly.
I do have an initial prototype that does this right now, it's got one
minor bug in that it doesn't create the '-part%n' symlinks to
/dev/sda$NUMBER correctly.
I had done a bit of refactoring work of iscsiadm, but it looks like your
refactoring for iscsiboot is much better, so I'll redo my prototype to
use the refactoring and post it to the list.
Alvin Starr
I toss the following script into /etc/udev/scripts
and BUS="scsi", PROGRAM="/etc/udev/scripts/iscsidev %b" NAME="%c%n"
into rules.d
==================
#!/usr/bin/perl
$arg = $ARGV[0];
($targname,$bus,$targ,$lun) = split(/\:/,$arg);
open(LOG, "> /tmp/iscsilog ");
print LOG "$ARGV[0] $ARGV[1] $ARGV[2] $ARGV[3] $ARGV[4]\n";
if( open(ADM, "/usr/sbin/iscsiadm -m session | ")) {
while(<ADM>){
print LOG "$_\n";
if( /\[0*$targname:/) {
($head,$addr,$fulltn) = split(/ /);
($head,$target_name) = split(/:/,$fulltn);
};
print LOG "name->$target_name\n";
}
} else {
$target_name = "iscsi-$targname";
}
print "$target_name";
=======================
this works for me using open-iscsi. It is a bit of a hack and I have not
gone back to clean it up so I take no resposiblity if it csuses your
system to crash or yout teeth to fall out.
--
Alvin Starr || voice: (416)585-9971
Interlink Connectivity || fax: (416)585-9974
al...@iplink.net ||
Mike Christie
> On Wed, Feb 08, 2006 at 11:58:41PM -0600, Mike Christie wrote:
>
>>>The tough part in writing a rule is finding the mapping between the
>>>iscsiadm -m session output, and the sysfs tree. So far it LOOKS like
>>>the $SID value from the session output matches up with the host number,
>>>but I don't know how reliable that is.
>>
>>it is reliable for software iscsi. if you end up using something like
>>qla4xxx then it will not match up.
>
> Ok, so when we get to qla4xxx using the valid of $SID and the output of
> iscsiadm to find Target we're going to be SOL. I'd guess the qla4xxx
> hardware will require having a TargetName sysfs node in the scsi_host
> location, which we can then utilize correctly.
>
Let me finish the boot junk this week. I will send you patches to do the
targetname, portal group, isid, and other info that is needed by HW
cards this weekend.
Robin H. Johnson
> >Ok, so when we get to qla4xxx using the valid of $SID and the output of
> >iscsiadm to find Target we're going to be SOL. I'd guess the qla4xxx
> >hardware will require having a TargetName sysfs node in the scsi_host
> >location, which we can then utilize correctly.
> Let me finish the boot junk this week. I will send you patches to do the
> targetname, portal group, isid, and other info that is needed by HW
> cards this weekend.