reliable udev rule for targetname to device mapping

[tmde...@vnet.ibm.com]

Hi,

I have read a lot of conversations about using udev to get a mapping
between targetname and the actual device and have even tried with some
success one of the rules.

I used the rule:
BUS="scsi", PROGRAM="/lib/udev/iscsidev %b" NAME="%c%n" SYMLINK="%k"

with the /lib/udev/iscsidev script as follows:
#!/usr/bin/python
import sys
import os
import re

arg = sys.argv[1]
(targname,bus,targ,lun) = arg.split(':')
for targets in os.popen('/sbin/iscsiadm -m session','r').readlines():
toMatch = re.compile('\[0*' + str(targname) + ':')
isMatch = toMatch.search(targets)
if(isMatch):
(head,addr,target_name) = targets.split();
sys.stdout.write(target_name)

script is based off of the perl version in:
http://groups.google.com/group/open-iscsi/browse_thread/thread/bc050f805c8f85c/fb0ff969e8da7629?q=udev&lnk=gst&rnum=2#fb0ff969e8da7629

In most cases this seems to work perfectly... it prints out the target
name
and there is a nice mapping (targetname to actual device). However, the
problem seems to be that the bus id %b in the udev rule above can get
out of sync with targname in the script.

targname refers to the 'xx' in the output of the command iscsiadm -m
session
for example:
# iscsiadm -m session
[xx:<record id>] <host>:<port>,1 targetname

with a quick look at the source code the xx seems to refer to the
session id, which is not necessarily the same as the bus id, hence the
problem of out of sync.

So my question is what is the recommended way to get this mapping that
is reliable?

Also, I have seen mention of supporting hotplugging directly what is
the status of that?

[tmde...@vnet.ibm.com]

Has anyone tried this type of rule or running a similar one?

Any experience with udev for this type of mapping?

Thanks in advance for any comments/suggestions/discussion.

Todd

[Todd Deshane]

I guess the question comes down to: Is there some attribute retrivable
with the iscsi front end tools, such as iscsiadm, that is likely to be
available to the kernel/udev (i.e. bus id, or other device info) in a
consistent/reliable way?

Thanks in advance,
Todd

[Jason Martens]

On Fri, 2006-07-21 at 13:33 -0400, Todd Deshane wrote:
> I guess the question comes down to: Is there some attribute retrivable
> with the iscsi front end tools, such as iscsiadm, that is likely to be
> available to the kernel/udev (i.e. bus id, or other device info) in a
> consistent/reliable way?

Did you look through /sys? Udev can pretty much use any attribute that
you can see in sys to create the device node, or symlinks to the device
node. See here: http://www.reactivated.net/writing_udev_rules.html .

Jason Martens

[Todd Deshane]

Hi Jason,
Thanks for the response.

I have looked in depth at /sys and tutorials on writing udev rules. I
understand the possibilities, but am not sure on the "best practices"
way to do it. I am sure there is some experience on it... is this the
best list to ask? Are there other people with experience with this?

> Jason Martens
>

Thanks,
Todd

> >

[Todd Deshane]

Hi All,

I have a working rule thanks to an off list response from Shawn Ferris.

here it is:

udev rule:
BUS="scsi", PROGRAM="/lib/udev/iscsidev.sh %b", SYMLINK+="iscsi/%c/part%
n"

iscsidev.sh script:
-------------------------------------------------------
#!/bin/sh

# Sample Path:
# /sys/class/scsi_host/host23/device/session19/iscsi_session:session19/targetname

BUS=${1}
HOST=${BUS%%:*}

file="/sys/class/scsi_host/host
${HOST}/device/session*/iscsi_session*/targetname"

# This is not an open-scsi drive
if [ -z "${file}" ]; then
exit 0
fi

target_name=$(cat ${file})

echo "${target_name}"
---------------------------------------------------------

Notice that you could use the following line of code to dynamically
detect the sysfs root (i.e. /sys), but with a read only
environment /etc/mtab is disabled so I just hardcoded /sys as the sysfs
root
---------------------------------------------------------
SYSFS=$(mount -t sysfs | awk '{print $3}' 2>/dev/null)
----------------------------------------------------------

Thanks for the responses,
Todd

[Albert Pauw]

It works, but,

1) if you login to another target the existing target links disappears.
The scsi device is ok, first target is on my machine /dev/sdb, next
target /dev/sdc, etc, but the links to the previous target, in my case
/dev/sdb (links part -> and part1 ->) are gone.

2) when logging out of the target the device links stay there.

3) this may be a FC5 problem, when logging into the target (Wasabi) I
seem to get a scsi generic device as well (/dev/sg1 etc). Your script
generates a link to that device as well, part2 ->

Albert

[Todd Deshane]

Hi Albert,

On Mon, 2006-07-24 at 09:49 -0700, Albert Pauw wrote:
> It works, but,
>
> 1) if you login to another target the existing target links disappears.
> The scsi device is ok, first target is on my machine /dev/sdb, next
> target /dev/sdc, etc, but the links to the previous target, in my case
> /dev/sdb (links part -> and part1 ->) are gone.

This doesn't happen for me

//login to a target
# iscsiadm -m node -r 85b1da -l

//device nodes created
# ls -l /dev/iscsi/*
total 0
lrwxrwxrwx 1 root root 9 Jul 24 12:15 part -> ../../sdc
lrwxrwxrwx 1 root root 10 Jul 24 12:15 part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Jul 24 12:15 part2 -> ../../sdc2

//login to another target
(none):~ # iscsiadm -m node -r 6e4f31 -l

//now have both device nodes
(none):~ # ls -l /dev/iscsi/*
/dev/iscsi/<mytargetname1>:
total 0
lrwxrwxrwx 1 root root 9 Jul 24 12:15 part -> ../../sdc
lrwxrwxrwx 1 root root 10 Jul 24 12:15 part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Jul 24 12:15 part2 -> ../../sdc2

/dev/iscsi/<mytargetname2>:
total 0
lrwxrwxrwx 1 root root 9 Jul 24 12:15 part -> ../../sdd
lrwxrwxrwx 1 root root 10 Jul 24 12:15 part1 -> ../../sdd1
lrwxrwxrwx 1 root root 10 Jul 24 12:15 part2 -> ../../sdd2

> 2) when logging out of the target the device links stay there.
>

//This isn't true for me either, when logging out:
# iscsiadm -m node -r 6e4f31 --logout

ls -l /dev/iscsi/*
total 0
lrwxrwxrwx 1 root root 9 Jul 24 12:15 part -> ../../sdc
lrwxrwxrwx 1 root root 10 Jul 24 12:15 part1 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Jul 24 12:15 part2 -> ../../sdc2

# iscsiadm -m node -r 85b1da --logout

# ls -l /dev/iscsi/*
/bin/ls: /dev/iscsi/*: No such file or directory

The device links get cleaned up as well as the sd* devices

> 3) this may be a FC5 problem, when logging into the target (Wasabi) I
> seem to get a scsi generic device as well (/dev/sg1 etc). Your script
> generates a link to that device as well, part2 ->
>

This I have noticed, in particular when it is an unpartitioned disk,
The fix for this is to change the udev rule to add the KERNEL=="sd*"
Also, I noticed the BUS= should be BUS==
so with the corrections the udev rule is:
KERNEL=="sd*", BUS=="scsi", PROGRAM="/lib/udev/iscsidev.sh %b", SYMLINK
+="iscsi/%c/part%n

I think 1) and 2) have to do with fedora packages...let me know if the
fix for 3) works for you. I am using opensuse 10.1 packages, last I knew
the FC5 packages were a little old, but the updated ones were on the
development branch of the mirror.

Hope that helps.

> Albert
>
Todd

[Albert Pauw]

Got 3) fixed, thanks, but here's a login to two targets:
i
[root@orange dev]# iscsiadm -m node -r a0a7c1 -l
[root@orange iscsi]# ls -l
lrwxrwxrwx 1 root root 9 Jul 24 21:04 /dev/iscsi/part -> ../../sdb
lrwxrwxrwx 1 root root 10 Jul 24 21:04 /dev/iscsi/part1 -> ../../sdb1
root@orange iscsi]#
[root@orange iscsi]# iscsiadm -m node -r a0a7c2 -l
[root@orange iscsi]# ls -l
lrwxrwxrwx 1 root root 9 Jul 24 21:04 /dev/iscsi/part -> ../../sdc
lrwxrwxrwx 1 root root 10 Jul 24 21:04 /dev/iscsi/part1 -> ../../sdc1

As you can see sdb is gone now.

Albert

[Albert Pauw]

Forgot number 2):

[root@orange iscsi]# iscsiadm -m node -r a0a7c2 -u
[root@orange iscsi]# ls -la /dev/iscsi/*

lrwxrwxrwx 1 root root 9 Jul 24 21:04 /dev/iscsi/part -> ../../sdc
lrwxrwxrwx 1 root root 10 Jul 24 21:04 /dev/iscsi/part1 -> ../../sdc1

And here udevinfo:
[root@orange iscsi]# udevinfo -V
udevinfo, version 084

[Todd Deshane]

try running udevmonitor in another terminal while you do that and see
what events are being generated

also you could try udevmonitor --env for more verbose output.

What version of udev are you using?
I have:
# udevinfo -V
udevinfo, version 085

you may also want to try getting verbose output to your syslog file
but editting the udev.conf file

cat /etc/udev/udev.conf
# udev.conf

# The initial syslog(3) priority: "err", "info", "debug" or its
# numerical equivalent. For runtime debugging, the daemons internal
# state can be changed with: "udevcontrol log_priority=<value>".
udev_log="debug"

Todd

[Albert Pauw]

It may have something to do, but Fedora has its scsi disks in /dev/sd*

However, the link in /dev/iscsi called part (and part1) are linked to
../../sdb1, which is effective in the root filesystem /. Does this ring
a bell for you?

Albert

[Albert Pauw]

As shown before, I have version 0.84 of udev.

Here's a logout and a login session with udevmonitor:

[root@orange ~]# udevmonitor
udevmonitor prints the received event from the kernel [UEVENT]
and the event which udev sends out after rule processing [UDEV]

UEVENT[1153769359.963522] remove@/class/scsi_generic/sg1
UEVENT[1153769359.963636] remove@/class/scsi_device/8:0:0:0
UEVENT[1153769359.963711] remove@/class/scsi_disk/8:0:0:0
UEVENT[1153769359.963784] remove@/block/sdb/sdb1
UEVENT[1153769359.963856] remove@/block/sdb
UEVENT[1153769359.963928]
remove@/devices/platform/host8/session3/target8:0:0/8: 0:0:0
UEVENT[1153769359.964000] remove@/class/iscsi_connection/connection3:0
UEVENT[1153769359.964072] remove@/class/iscsi_host/host8
UEVENT[1153769359.964187] remove@/class/scsi_host/host8
UEVENT[1153769359.964208] remove@/class/iscsi_session/session3
UDEV [1153769359.964756] remove@/class/scsi_generic/sg1
UDEV [1153769359.969534] remove@/class/scsi_device/8:0:0:0
UDEV [1153769359.973790] remove@/class/scsi_disk/8:0:0:0
UDEV [1153769359.979502] remove@/block/sdb/sdb1
UDEV [1153769359.984053]
remove@/devices/platform/host8/session3/target8:0:0/8: 0:0:0
UDEV [1153769359.989514] remove@/class/iscsi_connection/connection3:0
UDEV [1153769359.993746] remove@/class/iscsi_host/host8
UDEV [1153769360.003733] remove@/class/scsi_host/host8
UDEV [1153769360.007848] remove@/class/iscsi_session/session3
UDEV [1153769360.012093] remove@/block/sdb
UEVENT[1153769380.504471] add@/class/scsi_host/host9
UEVENT[1153769380.504771] add@/class/iscsi_host/host9
UEVENT[1153769380.504850] add@/class/iscsi_session/session4
UEVENT[1153769380.504920] add@/class/iscsi_connection/connection4:0
UDEV [1153769380.505716] add@/class/scsi_host/host9
UDEV [1153769380.511490] add@/class/iscsi_host/host9
UDEV [1153769380.516843] add@/class/iscsi_session/session4
UDEV [1153769380.528259] add@/class/iscsi_connection/connection4:0
UEVENT[1153769381.514644]
add@/devices/platform/host9/session4/target9:0:0/9:0:0 :0
UEVENT[1153769381.514769] add@/class/scsi_disk/9:0:0:0
UEVENT[1153769381.514968] add@/block/sdb
UEVENT[1153769381.515038] add@/block/sdb/sdb1
UEVENT[1153769381.515106] add@/class/scsi_device/9:0:0:0
UEVENT[1153769381.515273] add@/class/scsi_generic/sg1
UDEV [1153769381.519611]
add@/devices/platform/host9/session4/target9:0:0/9:0:0 :0
UDEV [1153769381.532795] add@/class/scsi_disk/9:0:0:0
UDEV [1153769381.586561] add@/class/scsi_generic/sg1
UDEV [1153769381.623699] add@/class/scsi_device/9:0:0:0
UDEV [1153769381.646559] add@/block/sdb
UDEV [1153769381.684652] add@/block/sdb/sdb1

[Albert Pauw]

Got it!!!!

Has to do with line breaks in iscsidev.sh:

file="/sys/class/scsi_host/host
${HOST}/device/session*/iscsi_session*/targetname"

should read as one line with NO space between host and ${HOST}

Now it works fine!

Thanks,

Albert

[Todd Deshane]

If I was you I would see if I could update the udev package.

The only other random thought I have right now is could there be a
synchronization problem with how the script and udev events are coming
in?
I will have to think on that one a little more...

What is your system setup are you running UP or SMP? 32 or 64bit? etc...

I am currently on a 64bit SMP box

> Albert
>

Todd
>
> >

[Todd Deshane]

On Mon, 2006-07-24 at 12:34 -0700, Albert Pauw wrote:
> Got it!!!!
>
Cool!

> Has to do with line breaks in iscsidev.sh:
>
> file="/sys/class/scsi_host/host
> ${HOST}/device/session*/iscsi_session*/targetname"
>

Must have got broken when sending across over email some where (or a
copy paste thing)

> should read as one line with NO space between host and ${HOST}
>
> Now it works fine!
>

Glad it works.

> Thanks,
>
> Albert
>
>
> >

[Albert Pauw]

Message to Mike,

is it a good idea to have the udev rules file and /lib/udev script
installed by the Makefile.
Effectively making this part of open-iscsi?

Albert

P.S. Thanks Todd, good work!

[Mike Christie]

Albert Pauw wrote:
> Message to Mike,
>
> is it a good idea to have the udev rules file and /lib/udev script
> installed by the Makefile.
> Effectively making this part of open-iscsi?
>

I am not done reading this thread :) But it could probably go in. What
is the rule and script? What does the /dev entry look like?

[Robin H. Johnson]

On Wed, Jul 19, 2006 at 07:58:30AM -0700, tmde...@vnet.ibm.com wrote:
> I have read a lot of conversations about using udev to get a mapping
> between targetname and the actual device and have even tried with some
> success one of the rules.

Update your udev, and use path_id.

You'll get something like
/dev/disk/by-path/ip-${iscsi_address}:${iscsi_port}-iscsi-${iscsi_tgtname}

Eg:
/dev/disk/by-path/ip-10.0.0.1:3270-iscsi-mytargetname

--
Robin Hugh Johnson
E-Mail : rob...@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85

[Albert Pauw]

Hang on before incorporating this, I noticed another error.
My machine as a SATA disk which becomes at startup /dev/sda.

Now the script creates wrong links in /dev/iscsi again (part, part1,
part2, part2).
This needs to be filtered out.

Todd?

Albert

[Albert Pauw]

Ok, my knowledge of udev is rather limited, but I managed to have
ordinary scsi disks handled decently (albeit not ignored, which would
be better).

Here is the file /etc/udev/rules.d/open-iscsi.rules:

KERNEL=="sd*", BUS=="scsi", PROGRAM="/lib/udev/iscsidev.sh %b",
SYMLINK+="iscsi/%c/part%n"

(actually just one line).

And here is the script /lib/udev/iscsidev.sh:

#!/bin/sh
# Sample Path:
#
/sys/class/scsi_host/host23/device/session19/iscsi_session:session19/targetname

BUS=${1}
HOST=${BUS%%:*}

file="/sys/class/scsi_host/host${HOST}/device/session*/iscsi_session*/targetname"

# This is not an open-scsi drive

if [ ! -f "${file}" ]; then
echo "disk${HOST}"
exit 0
fi

target_name=$(cat ${file})

echo "${target_name}"

The changes I made are ! -f instead of -z (didn't work, gave error),
and an echo "disk${HOST}"
which adds an entry for an ordinary scsi disk, instead of putting the
links to the partitions as /dev/iscsi/part -> ../../sda, which is
wrong. So it now shows as /dev/iscsi/disk0/part -> ../../sda, etc.

If someone can come up with a cleaner approach (not including ordinary
scsi disks at all) that would be better.

Albert

[Albert Pauw]

/sys/class/scsi_host/host23/device/session19/iscsi_session:session19/targetname

needs to be removed, it's a line break as it was originally a comment!!

Albert

[Albert Pauw]

Actually it doesn't work, now all disks including iscsi disks get
marked as disk0, disk1, etc.

The file string doesn't get expanded properly in the if statement, hmm,
I am a bit stuck here.

Must be the high temperatures ;-)

[Todd Deshane]

I think the problem is this line (after the if ! -f ${file}):
echo "disk${HOST}"

That line is not necessary, the normal disks don't need symlinks to
them.

Todd

[Todd Deshane]

On Tue, 2006-07-25 at 02:22 -0700, Albert Pauw wrote:

> Ok, my knowledge of udev is rather limited, but I managed to have
> ordinary scsi disks handled decently (albeit not ignored, which would
> be better).
>

This script shouldn't try to handle normal scsi disks, other rules can
do that better

[Todd Deshane]

On Mon, 2006-07-24 at 19:53 -0700, Robin H. Johnson wrote:
> On Wed, Jul 19, 2006 at 07:58:30AM -0700, tmde...@vnet.ibm.com wrote:
> > I have read a lot of conversations about using udev to get a mapping
> > between targetname and the actual device and have even tried with some
> > success one of the rules.
> Update your udev, and use path_id.
>
> You'll get something like
> /dev/disk/by-path/ip-${iscsi_address}:${iscsi_port}-iscsi-${iscsi_tgtname}
>
> Eg:
> /dev/disk/by-path/ip-10.0.0.1:3270-iscsi-mytargetname
>

so you are suggesting a rule like:

/etc/udev/rules.d/50-udev.rules:
KERNEL=="*[0-9]", ENV{ID_FS_UUID}=="?*", SYMLINK \
+="disk/by-uuid/$env{ID_FS_UUID}"

but with the targetname and ip and such replaced and the rule similar to
as it is with BUS=="scsi" and KERNEL=="sd*", etc... and have the script
still be the program?

should we put this info in the environment with the script?
is that done with export (in bash)? do you have a code snippet of how to
do it you would like to share?

Thanks,
Todd

[Albert Pauw]

Yes, I know, it should not be handled at all.

But unfortunately, the script does. Any idea to filter out the ordinary
scsi (and sata) disks?

[Todd Deshane]

I don't have reasonable enough access to test adding normal scsi/sata
drives right now, but maybe this would be a good question to pose the
linux-hotplug-devel list?

One thing I can think of of hand, udev supports a last_rule option.
You could put your handling of normal scsi drives first and when after
that rule fires you could use the last_rule option.

The only thing I am not sure of is what assumptions can be made about
normal scsi devices vs. iscsi or vice versa, once we have that down it
should be straight forward. One thing that could be watched is the
output of udevmonitor --env which shows a lot of output when devices are
plugged in, that may give some clues. You could also edit the udev.conf
file to log in "debug" mode, which produces a lot of output to your
syslogger.

Hope that helps. When I get back to school in the fall I should have
more time and access to do testing on this.

Hope that helps,
Todd

>
> >

[Albert Pauw]

Ok,

this is it. Maybe Mike could see if he wants it included in the
Makefile.

There are two files "55-openiscsi.rules" and "iscsidev.sh".

55-openiscsi.rules has one line and should be put in /dev/udev/rules.d:

KERNEL=="sd*", BUS=="scsi", PROGRAM="/lib/udev/iscsidev.sh %b",
SYMLINK+="iscsi/%c/part%n"

iscsidev.sh should be put in /lib/udev/iscsidev.sh or another place as
long as the reference in the rules file is adapted accordingly:
#!/bin/sh

BUS=${1}
HOST=${BUS%%:*}

[ -e /sys/class/iscsi_host ] || exit 1

file="/sys/class/iscsi_host/host${HOST}/device/session*/iscsi_session*/targetname"

target_name=$(cat ${file})

# This is not an open-scsi drive

if [ -z "${target_name}" ]; then
exit 1
fi

echo "${target_name}"

Now, whenever you log into a target there is an entry like:
[root@orange dev]# ls -laR /dev/iscsi
/dev/iscsi:
total 0
drwxr-xr-x 3 root root 60 Jul 26 17:38 .
drwxr-xr-x 14 root root 3900 Jul 26 17:38 ..
drwxr-xr-x 2 root root 80 Jul 26 17:38
iqn.2000-05.com.wasabisystems.storagebuilder:cyan-1

/dev/iscsi/iqn.2000-05.com.wasabisystems.storagebuilder:cyan-1:
total 0
drwxr-xr-x 2 root root 80 Jul 26 17:38 .
drwxr-xr-x 3 root root 60 Jul 26 17:38 ..
lrwxrwxrwx 1 root root 9 Jul 26 17:38 part -> ../../sdb
lrwxrwxrwx 1 root root 10 Jul 26 17:38 part1 -> ../../sdb1

So know you always know which target to pick for mounting, as it is
found in /dev/iscsi with the partitions as subdirectories.
If you logout the target it is removed.

Thanks to Todd Deshane.

Albert

[Albert Pauw]

I noticed two caveats with the abovementioned:

1) when you have created partitions on the empty target, you have to
log out and log in again to get the partitions link. No big deal.

2) when your target exports more luns, only the last one is seen and
made, but of a bummer really.

Albert

[Todd Deshane]

On Wed, 2006-07-26 at 12:30 -0700, Albert Pauw wrote:
> I noticed two caveats with the abovementioned:
>
> 1) when you have created partitions on the empty target, you have to
> log out and log in again to get the partitions link. No big deal.
>

What do you mean by empty target?

Is this after running discovery to get the new record id to use?

I guess I just don't understand the use case scenario...

> 2) when your target exports more luns, only the last one is seen and
> made, but of a bummer really.
>

I hadn't known about this possibility... targets that export multiple
drives seems confusing.

> Albert
>
>
Todd

> >

[Albert Pauw]

> What do you mean by empty target?

I meant a 'bare' disk, with no partition table on it, so first thing is
to create one on the target disk, then logout en login again, and a
link to the targets partition is made.

> I hadn't known about this possibility... targets that export multiple drives seems confusing.

It's the scsi concept of LUNs, using one target with more than one lun
makes it possible to login into the target once, and get multiple disks
in one go. Of course you could this by partitioning your single lun.
But using multiple luns gives you the possibility of putting the
different luns on different disk types (fast, slow, raid 0, raid 1,
raid 5, etc).

As said, the first problem is a no-brainer, just logout and login again
after creating the partition(s), you just have to do this one anyway.
The second one is a tricky one, but for the moment I can live with
that.

Albert

[Hannes Reinecke]

Albert Pauw wrote:
> Ok,
>
> this is it. Maybe Mike could see if he wants it included in the
> Makefile.
>
> There are two files "55-openiscsi.rules" and "iscsidev.sh".
>
> 55-openiscsi.rules has one line and should be put in /dev/udev/rules.d:
> KERNEL=="sd*", BUS=="scsi", PROGRAM="/lib/udev/iscsidev.sh %b",
> SYMLINK+="iscsi/%c/part%n"
>
> iscsidev.sh should be put in /lib/udev/iscsidev.sh or another place as
> long as the reference in the rules file is adapted accordingly:

right, I think it's time to chime in.

Not long ago we've implemented something called 'persistent device
names' in udev. It basically boils down to creating symlinks to the
devices the name of which is based on some physical parameters of the
said disk, not the logical names assigned by the kernel.
This way the symlink will always point to the same drive, regardless of
the loading order within the kernel.

The names are organized in two groups; the symlinks of one group are
created from the physical path to a device (named 'by-path') and the
symlinks in the other group are created from the physical device
identification (named 'by-id'). So for iscsi, this maps to

/dev/disk/by-path/iscsi-<IP-number>-<Targetname>

where <IP-number> is the ip number of the iSCSI target. I didn't see any
reason to introduce specific rules for 'by-id' when using iscsi, as the
normal VPD page 0x83 should be sufficient to identify the drive.
Might be persuaded otherwise, though.

And based on the above I don't see the need for any iscsi specific udev
rules, either.

Note that currently there is a race condition with udev as the
targetname is only set in sysfs _after_ the uevent has been sent. So
it's possible that udev is not able to get the proper targetname as it
hasn't been set yet. I'm working on that to get it resolved.

Cheers,

Hannes
--
Dr. Hannes Reinecke ha...@suse.de
SuSE Linux Products GmbH S390 & zSeries
Maxfeldstraße 5 +49 911 74053 688
90409 Nürnberg http://www.suse.de

[Albert Pauw]

Any final solution is fine with me, the most standard one is the one I
would prefer,
if that's your solution, then I am happy to use it.

> /dev/disk/by-path/iscsi-<IP-number>-<Targetname>

> where <IP-number> is the ip number of the iSCSI target. I didn't see any
> reason to introduce specific rules for 'by-id' when using iscsi, as the
> normal VPD page 0x83 should be sufficient to identify the drive.
> Might be persuaded otherwise, though.

Just curious, how are you going to handle one target with multiple
luns?

Albert

[Hannes Reinecke]

Albert Pauw wrote:
> Any final solution is fine with me, the most standard one is the one I
> would prefer,
> if that's your solution, then I am happy to use it.
>

It's actually already in udev, so you'll have it automatically.

>> /dev/disk/by-path/iscsi-<IP-number>-<Targetname>
>
>> where <IP-number> is the ip number of the iSCSI target. I didn't see any
>> reason to introduce specific rules for 'by-id' when using iscsi, as the
>> normal VPD page 0x83 should be sufficient to identify the drive.
>> Might be persuaded otherwise, though.
>
> Just curious, how are you going to handle one target with multiple
> luns?
>

Erks.
Got me there. Yes, of course we should add multiple luns. What about the
following:

/dev/disk/by-path/ip-<IP-number>-iscsi-<Targetname>:<lun>

Acceptable?

[Albert Pauw]

> /dev/disk/by-path/ip-<IP-number>-iscsi-<Targetname>:<lun>

Yes, looks fine to me.

Next step would be an '/etc/iscsitab'. There is already provision for
automatic login in open-iscsi for targets,
if used you don't have to take care of the recordnrs of open-iscsi,
just mount the correct path to the proper mount point
(with the appropriate options).

Albert

[Hannes Reinecke]

Well, you can do it nowadays.
At least with SLES10 :-)
just add the option 'hotplug' to /etc/fstab.
Then /etc/init.d/boot.localfs will ignore the device if not present;
once it's initialized udev will mount it automatically.

The tricky bit is to have it unmounted automatically ...
Unfortunately I haven't been able to solve that one properly :-(

[Albert Pauw]

Works differently on Fedora ;-)

Maybe an iscsitab would be more practical, with an accompanying
start/stop script which mounts/unmounts.

[Todd Deshane]

Hi Hannes,

On Thu, 2006-07-27 at 13:22 +0200, Hannes Reinecke wrote:

> It's actually already in udev, so you'll have it automatically.
>

What version of udev and which rule?

> >> /dev/disk/by-path/iscsi-<IP-number>-<Targetname>
> >
since I don't see this by-path entry.

> >> where <IP-number> is the ip number of the iSCSI target. I didn't see any
> >> reason to introduce specific rules for 'by-id' when using iscsi, as the
> >> normal VPD page 0x83 should be sufficient to identify the drive.
> >> Might be persuaded otherwise, though.
> >
> > Just curious, how are you going to handle one target with multiple
> > luns?
> >
> Erks.
> Got me there. Yes, of course we should add multiple luns. What about the
> following:
>
> /dev/disk/by-path/ip-<IP-number>-iscsi-<Targetname>:<lun>
>
> Acceptable?
>
> Cheers,
>
> Hannes

Thanks,
Todd

[Albert Pauw]

Yep, on Fedora there is no such standard thing like

/dev/disk/by-path/iscsi-<IP-number>-Target name

In fact iscsi-target (with two targets, one has a partition on it)
shows up like:

lrwxrwxrwx 1 root root 9 Jul 27 17:53 pci-platform-scsi-0:0:0:0 ->
../../sdb
lrwxrwxrwx 1 root root 9 Jul 27 17:53 pci-platform-scsi-0:0:0:1 ->
../../sdc
lrwxrwxrwx 1 root root 10 Jul 27 17:53 pci-platform-scsi-0:0:0:1-part1
-> ../../sdc1

(sda is my sata disk), so it is not really recognisable as the iscsi
target.

Albert

[Albert Pauw]

Hannes,

is this a typical SuSE udev rule for iscsi? If so, would it be possible
to use it under Fedora?

Albert

[Patrick Mansfield]

It is noted in the udev 093 changelog, you could try building it yourself.
Looking at SRPMS for FC, FC devel has udev 95, FC5 has 84. I guess FC6
has/will have it, not sure where to find FC6T1.

http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;h=a92b509cb4d2866809965dbb55299ec309db8564;hb=353b00edbcd4da7a2758b50e1e4abf18ac2c6625;f=ChangeLog

Above has:

Summary of changes from v092 to v093
============================================

Hannes Reinecke:
path_id: add support for iSCSI devices

-- Patrick Mansfield

[Mike Christie]

So is

/dev/disk/by-path/iscsi-<IP-number>-<Targetname>

for a specific disk or is that some dir that contains the devices on
that target, or is there more like

/dev/disk/by-path/iscsi-<IP-number>-<Targetname>-some-lu-id?

Does udev make the name part by part as each piece is added? I ask
because when the scsi_device is finally added the targetname and ip addr
and all the other iscsi values should be in place. Is it possible to
just handle the scsi_device add event and then build the udev name,
because at that time all the values should be in place? Or do you have
to listen for the session add, then the target, then the connection?

But yeah I agree, I do not like the /dev/iscsi stuff. It should nice if
we could just override the by-path links. The default by-paths links we
get are not very useful for iscsi.

[Mike Christie]

He he, read the rest of the thread finally, nevermind.

>
> Does udev make the name part by part as each piece is added? I ask
> because when the scsi_device is finally added the targetname and ip addr
> and all the other iscsi values should be in place. Is it possible to
> just handle the scsi_device add event and then build the udev name,
> because at that time all the values should be in place? Or do you have
> to listen for the session add, then the target, then the connection?
>
> But yeah I agree, I do not like the /dev/iscsi stuff. It should nice if
> we could just override the by-path links. The default by-paths links we
> get are not very useful for iscsi.
>

Nevermind again. I read the rest of the thread. I guess it is fedora 5
that defaults to the old by path links.

I guess I am just asking about the symlink creation and the race.

[Albert Pauw]

Hi Mike,

hopefully FC5 will have the latest udev soon, for the moment I have to
do with v0.84, in which case the stuff by Todd (and a little bit of me)
works fine, as long as you have a single lun on the target.

I agree about having a standard way of doing all this, for all main
distributions (Fedora, SuSE, etc). And of course some (standard)
infrastructure of mounting the target, either through the way SuSE can
do this already (according to Hannes) or something like a
/etc/iscsitab.

Just my two cents,

Albert

[Hannes Reinecke]

Well, it's actually part of udev nowadays; should be in
/etc/udev/rules.d/60-persistent-storage.rules

But then, as RH does not believe in dynamic device configuration, I
wouldn't wonder if they stripped it down somewhat.