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 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467390 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 open-iscsi.org release becuase they have all the updated fixes. Also, I am not sure if this http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467390 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 open-iscsi@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
