On 22/05/14 17:45, Ritesh Raj Sarraf wrote:
Please keep the bug email in the recipient list.
On 05/22/2014 09:37 PM, Craig Barnes wrote:
Could you please explain what is "heavy load" here? Is it iSCSI traffic ?
To simulate heavy load ( it does not need to be too heavy ), I initiated
4 dd operations to files on the device, then issued the stop.
I am assuming you are writing to the iscsi devices. If yes, then
there's no reason for this to not fail.
Yes I am writing to the iscsi device, the devices get removed as
expected, the service initiates a stop, only the kernel module unload
fails, I assume waiting for the service to finish or disks to sync.
Is there any reason why this shouldn't successfully stop?
# service iscsitarget stop
[ ok ] Removing iSCSI enterprise target devices: :.
[ ok ] Stopping iSCSI enterprise target service: :.
[....] Removing iSCSI enterprise target modules: :FATAL: Module
iscsi_trgt is in use.
Changing etc/init/init.debian to use `rmmod --wait` instead of
`modprobe -r` corrects this issue.
We use 'modprobe -r' to ensure that dependencies also get unloaded. With
'rmmod --wait', wouldn't it hang the shutdown sequence ?
I wasn't able to determine any dependant libraries on my system, if
there are any in other packages that depend on iscsi_trgt then I would
be happy to test this and improve my solution.
Yes. THis one does not have any direct dependencies. As practice, I use
modprobe.
Ok, so
a) what is the worst thing that could happen using rmmod --wait
b) is there a better way to do this? maybe wait 2 secs and try again
with modprobe -r?
c) if we fail at the module shouldn't we bring everything else back
again?
Our deployment has many targets so this is not practical for our use case.
I can see from the other init implementations that init.debian is the
only one that unloads the modules, is this still necessary?
The userspace daemon is very basic. The sessions are handled in the
kernel. So when you ask iscsitarget to stop, you want the session also
terminated, for which, we need to unload the module.
I haven't confirmed it on the iscsitarget code but for open-iscsi (the
initiator) that is the case.
Yes. That is the case. Look at conn.c in the sources.
Sorry my c is a bit rusty and I am no kernel dev. But I understand and
appreciate your explanation.
However I did find this...
http://sourceforge.net/p/iscsitarget/code/343/
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
