# create a new target with one lun
root@host:~# ietadm --op new --tid=1 --params=Name=mytarget
root@host:~# ietadm --op new --tid=1 --lun=0 --params=Path=/dev/myvol
root@host:~# cat /proc/net/iet/volume
tid:1 name:mytarget
lun:0 state:0 iotype:fileio iomode:wt blocks:204800 blocksize:512
path:/dev/myvol
root@host:~# cat /proc/net/iet/session
tid:1 name:mytarget
# login from client
clayg@client:~$ sudo iscsiadm -m node -T mytarget -p host:3260 --login
Logging in to [iface: default, target: mytarget, portal: host,3260]
Login to [iface: default, target: mytarget, portal: host,3260]: successful
# obviously can't delete while in use
root@host:~# cat /proc/net/iet/session
tid:1 name:mytarget
sid:281475182035456 initiator:iqn.1993-08.org.debian:01:cd8bd6ba8c3e
cid:0 ip:client state:active hd:none dd:none
root@storage1-SATA:~# ietadm --op delete --tid=1
Device or resource busy.
# logout from client
clayg@client:~$ sudo iscsiadm -m session --logout
Logging out of session [sid: 12, target: mytarget, portal: host,3260]
Logout of [sid: 12, target: mytarget, portal: host,3260]: successful
# doesn't seem to be in use any longer
root@host:~# cat /proc/net/iet/session
tid:1 name:mytarget
# but still can't delete it
root@host:~# ietadm --op delete --tid=1
Device or resource busy.
Obviously restarting ietd will allow the target to be removed, but at
the expense of forcing all the other target's initiators to have to
reconnect. Not as obvious to me, but I found that if I am able to
delete the session from my end (i.e. --op delete --tid --sid --cid,
before the initiator logs out) - then I can delete the target cleanly.
I haven't been able to replicate this behavior on fresh build from
source on a 3.0 kernel. The problem seems to manifest on Ubuntu's
12.04 (precise) release, but not 11.10 (oneiric).
Can anyone duplicate or verify if this is a regression? This change
is unexpected and not desirable for me. Is there a reason why the
delete operation seems to behave differently from 3.0 to 3.2?
Best Regards,
Clay Gerrard
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Iscsitarget-devel mailing list
Iscsitar...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel
Have you tried to remove the LUN first from the target and then the target? All my own cleanup code does that in that order.
> # doesn't seem to be in use any longer
> root@host:~# cat /proc/net/iet/session
> tid:1 name:mytarget
> # but still can't delete it
> root@host:~# ietadm --op delete --tid=1
> Device or resource busy.
>
Steffen
Interesting, were there any warnings during compiling on 3.2 kernel?
Maybe a change in mutex API?
> Can anyone duplicate or verify if this is a regression? This change
> is unexpected and not desirable for me. Is there a reason why the
> delete operation seems to behave differently from 3.0 to 3.2?
Yes, please anyone else running 3.2 kernel can replicate this?
-Ross
______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.
On Wed, Mar 28, 2012 at 10:27 AM, Steffen Plotner <swpl...@amherst.edu> wrote:
>
> Have you tried to remove the LUN first from the target and then the target? All my own cleanup code does that in that order.
>
>
Thanks for the reply,
I used to do that, but it didn't seem to be necessary on more recent
builds. I had tried it before (and verified just now) - it doesn't
make a difference on a 3.2 kernel.
root@host32:~# cat /proc/net/iet/volume
tid:1 name:mytarget
lun:0 state:0 iotype:blockio iomode:wt blocks:204800 blocksize:512
path:/dev/volume-group/vol1
root@host32:~# ietadm --op delete --tid=1 --lun=0
root@host32:~# cat /proc/net/iet/volume
tid:1 name:mytarget
root@host32:~# ietadm --op delete --tid=1
Device or resource busy.
root@host30:~# cat /proc/net/iet/volume
tid:1 name:mytarget
lun:0 state:0 iotype:blockio iomode:wt blocks:204800 blocksize:512
path:/dev/volume-group/vol1
root@host30:~# ietadm --op delete --tid=1
root@host30:~# cat /proc/net/iet/volume
root@host30:~#
Best Regards,
Clay Gerrard
>
> Interesting, were there any warnings during compiling on 3.2 kernel?
No. Well none that seemed important ;)
root@precise:~/iscsitarget-devel# make
make -C usr
make[1]: Entering directory `/root/iscsitarget-devel/usr'
cc -O2 -fno-inline -Wall -Wstrict-prototypes -I../include
-D_GNU_SOURCE -c -o ietd.o ietd.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -I../include
-D_GNU_SOURCE -c -o iscsid.o iscsid.c
iscsid.c: In function ‘text_scan_login’:
iscsid.c:290:8: warning: variable ‘err’ set but not used
[-Wunused-but-set-variable]
iscsid.c: In function ‘login_start’:
iscsid.c:389:15: warning: variable ‘alias’ set but not used
[-Wunused-but-set-variable]
cc -O2 -fno-inline -Wall -Wstrict-prototypes -I../include
-D_GNU_SOURCE -c -o conn.o conn.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -I../include
-D_GNU_SOURCE -c -o session.o session.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -I../include
-D_GNU_SOURCE -c -o target.o target.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -I../include
-D_GNU_SOURCE -c -o message.o message.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -I../include
-D_GNU_SOURCE -c -o ctldev.o ctldev.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -I../include
-D_GNU_SOURCE -c -o log.o log.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -I../include
-D_GNU_SOURCE -c -o chap.o chap.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -I../include
-D_GNU_SOURCE -c -o event.o event.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -I../include
-D_GNU_SOURCE -c -o param.o param.c
param.c: In function ‘minimum_check_val’:
param.c:99:6: warning: variable ‘err’ set but not used
[-Wunused-but-set-variable]
param.c: In function ‘maximum_check_val’:
param.c:111:6: warning: variable ‘err’ set but not used
[-Wunused-but-set-variable]
cc -O2 -fno-inline -Wall -Wstrict-prototypes -I../include
-D_GNU_SOURCE -c -o plain.o plain.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -I../include
-D_GNU_SOURCE -c -o isns.o isns.c
isns.c: In function ‘print_scn_pdu’:
isns.c:596:49: warning: variable ‘sequence’ set but not used
[-Wunused-but-set-variable]
isns.c:596:36: warning: variable ‘transaction’ set but not used
[-Wunused-but-set-variable]
isns.c:596:29: warning: variable ‘flags’ set but not used
[-Wunused-but-set-variable]
isns.c:596:11: warning: variable ‘function’ set but not used
[-Wunused-but-set-variable]
isns.c: In function ‘qry_rsp_handle’:
isns.c:647:49: warning: variable ‘sequence’ set but not used
[-Wunused-but-set-variable]
isns.c:647:29: warning: variable ‘flags’ set but not used
[-Wunused-but-set-variable]
isns.c:647:11: warning: variable ‘function’ set but not used
[-Wunused-but-set-variable]
isns.c: In function ‘isns_handle’:
isns.c:755:49: warning: variable ‘sequence’ set but not used
[-Wunused-but-set-variable]
isns.c:755:36: warning: variable ‘transaction’ set but not used
[-Wunused-but-set-variable]
isns.c:755:29: warning: variable ‘flags’ set but not used
[-Wunused-but-set-variable]
isns.c:755:21: warning: variable ‘length’ set but not used
[-Wunused-but-set-variable]
isns.c:754:11: warning: variable ‘result’ set but not used
[-Wunused-but-set-variable]
isns.c: In function ‘isns_scn_handle’:
isns.c:855:49: warning: variable ‘sequence’ set but not used
[-Wunused-but-set-variable]
isns.c:855:29: warning: variable ‘flags’ set but not used
[-Wunused-but-set-variable]
isns.c:855:21: warning: variable ‘length’ set but not used
[-Wunused-but-set-variable]
cc -O2 -fno-inline -Wall -Wstrict-prototypes -I../include
-D_GNU_SOURCE -c -o md5.o md5.c
cc -O2 -fno-inline -Wall -Wstrict-prototypes -I../include
-D_GNU_SOURCE -c -o sha1.o sha1.c
cc ietd.o iscsid.o conn.o session.o target.o message.o ctldev.o log.o
chap.o event.o param.o plain.o isns.o md5.o sha1.o -o ietd
cc -O2 -fno-inline -Wall -Wstrict-prototypes -I../include
-D_GNU_SOURCE -c -o ietadm.o ietadm.c
cc ietadm.o param.o -o ietadm
make[1]: Leaving directory `/root/iscsitarget-devel/usr'
make -C /lib/modules/3.2.0-18-virtual/build
SUBDIRS=/root/iscsitarget-devel/kernel modules
make[1]: Entering directory `/usr/src/linux-headers-3.2.0-18-virtual'
CC [M] /root/iscsitarget-devel/kernel/tio.o
CC [M] /root/iscsitarget-devel/kernel/iscsi.o
CC [M] /root/iscsitarget-devel/kernel/nthread.o
/root/iscsitarget-devel/kernel/nthread.c: In function ‘do_recv’:
/root/iscsitarget-devel/kernel/nthread.c:147:1: warning: the frame
size of 1104 bytes is larger than 1024 bytes [-Wframe-larger-than=]
CC [M] /root/iscsitarget-devel/kernel/wthread.o
CC [M] /root/iscsitarget-devel/kernel/config.o
CC [M] /root/iscsitarget-devel/kernel/digest.o
CC [M] /root/iscsitarget-devel/kernel/conn.o
CC [M] /root/iscsitarget-devel/kernel/session.o
CC [M] /root/iscsitarget-devel/kernel/target.o
CC [M] /root/iscsitarget-devel/kernel/volume.o
CC [M] /root/iscsitarget-devel/kernel/iotype.o
CC [M] /root/iscsitarget-devel/kernel/file-io.o
CC [M] /root/iscsitarget-devel/kernel/null-io.o
CC [M] /root/iscsitarget-devel/kernel/target_disk.o
CC [M] /root/iscsitarget-devel/kernel/event.o
CC [M] /root/iscsitarget-devel/kernel/param.o
CC [M] /root/iscsitarget-devel/kernel/block-io.o
CC [M] /root/iscsitarget-devel/kernel/ua.o
CC [M] /root/iscsitarget-devel/kernel/persist.o
LD [M] /root/iscsitarget-devel/kernel/iscsi_trgt.o
Building modules, stage 2.
MODPOST 1 modules
CC /root/iscsitarget-devel/kernel/iscsi_trgt.mod.o
LD [M] /root/iscsitarget-devel/kernel/iscsi_trgt.ko
make[1]: Leaving directory `/usr/src/linux-headers-3.2.0-18-virtual'
>
> Maybe a change in mutex API?
>
I'm quite certain I would know. That's why I posted here :D
>> Can anyone duplicate or verify if this is a regression? This change
>> is unexpected and not desirable for me. Is there a reason why the
>> delete operation seems to behave differently from 3.0 to 3.2?
>
> Yes, please anyone else running 3.2 kernel can replicate this?
>
> -Ross
Thanks for the help,
Clay Gerrard