Rudy Gevaert wrote:
> Hello,
> So it seems that running 2.6.18 (stock Debian kernel) with open-iscsi 
> 2.0.730-1etch1 doesn't give me any problems regarding the start and 
> stopping.  (Although one iscsid process is still running when I stop it 
> with the init script.)

That is a bug in iscsid not handling the kill signals right. Other 
scripts do a killall -9 iscsid type of thing but debian does not. Now 
iscsid handles the normal stop signals so there is no need to do killall -9.

> Doing
>   echo - - - > /sys/class/scsi_host/hostX/scan
> effectively rescans my target, so the need to upgrade to a later version 
>   is not necessary (for me).
> However using a later open-iscsi (2.0.865-1) has some problems on 2.6.18 
> kernel.  It isn't really stopping when I stop it.  The devices are still 
>    available.

I do not think 2.0.865 works with the 2.6.18 upstream kernel. The 
interface was not stable until 2.6.21, so before that you had to upgrade 
tools with the kernel or the distro kernel had to be updated.

> Debian bug has 
> some notes about the newer version of open-iscsi not working with 
> kernels below 2.6.25.

I am not sure if that is worded right. The scsi userspace interface we 
used was broken and that broke the open-iscsi tools. The newest version 
of open-iscsi tools contain a fix, but they require a kernel fix trhat 
is in 2.6.25.

Alternatively, you can use the kenrel modules and tools in the release becuase they have all the updated fixes.

Also, I am not sure if this affects you. 
With netapp targets (just guessing you have a netapp target because of 
the naming of your rule below) I think you can control the write back 
cache settings.  If it is disabled like here:

Apr  1 12:04:07 meanminna kernel: sd 9:0:0:8: [sdo] Write cache: 
disabled, read cache: enabled, doesn't support DPO or FUA

then you will not hit the problem.

> 2.6.24 is in Debian unstable, without xen for amd64 and I need xen 
> support, so I'm rather stuck with 2.6.18.
> Stopping open-iscsi also deletes the correct /dev/disk/by-path links. 
> But I'm still having problems with a udev rule I wrote myself:
> jlyj43j:/etc/udev/rules.d# cat z99_netapp_persistant.rules
> # This file contains the rules needed to create persistent device names.
> # we are only interested in add actions for block devices
> SUBSYSTEM!="block",                     GOTO="no_volume_id"
> ACTION!="add",                          GOTO="no_volume_id"
> # skip xen virtual hard disks
> DRIVERS=="vbd",                         GOTO="no_hardware_id"
> KERNEL=="sd*[!0-9]",\
>          IMPORT{program}="netappluns $KERNEL"
> KERNEL=="sd*[!0-9]", 
> ENV{VFILER}=="?*",ENV{LUN}=="?*",ENV{VOLUME}=="?*",ENV{STATE}=="GOOD", \
>          SYMLINK+="disk/by-vfiler/$ENV{VFILER}/$ENV{VOLUME}/$ENV{LUN}"
> # end of processing
> LABEL="no_volume_id"
> The problems seems to be a timing issue.  My 'netappluns' script is 
> acting on /dev/sdX.  But /dev/sdX isn't yet created by udev.  Thus failing.
> Calling udevtrigger manually, after /dev/sdX is created, creates the 
> relevant links.
> Are there any guidelines for integrating udev with open-iscsi?

No. There are some threads on the list from users doing their custom 
scripts, but normally we probably prefer to user the distros default 
rules. If you have the most uptodate ones they should normally be fine 
for what you want to do. If they are not then we should talk about why not.

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at

Reply via email to