svn commit: r291911 - head/sys/dev/iscsi
Steven Hartland
steven at multiplay.co.uk
Mon Dec 7 15:28:05 UTC 2015
On 07/12/2015 13:10, Edward Tomasz Napierała wrote:
> isn't supposed to remove working iSCSI sessions.
>> I didn't notice your change in head / stable/10 compared to releng, so
>> I'm testing further updates now.
> Well, the difference is pretty crucial here - previously, the purpose of
> iscsi_shutdown() was to disconnect the sessions during shutdown. Now it
> doesn't do that at all - established connections are kept intact, it just
> disables reconnections. And for this to work, it needs to happen as soon
> as possible during shutdown.
More information on why this needs to happen as soon as possible would
be appreciated.
>
>> Currently shutdown is run too early and actually doesn't actually
>> terminate any sessions.
> What does "currently" mean in this context?
HEAD / stable/10.
>
>> My current theory is the issue you tried to fix in 286226 is actually
>> caused by the iscsi_maintenance_thread preferring reconnect over
>> terminate, so what you where seeing was the terminate never action for
>> reconnecting sessions. I'm currently trying to validate that theory now.
>>
>> If I'm right then the fix should be to revert the majority of 286226 and
>> move the processing of terminate above reconnect in
>> iscsi_maintenance_thread.
> I don't think that would work. The reason that the sessions don't
> terminate (in 11-CURRENT) is that they are not supposed to - unmounting
> filesystems will write data to LUNs, and we don't want to break that.
Agreed, which is why I believe it needs to do so after filesystem
shutdown, not before, which is what was happening prior to r286226.
> The only reason iscsi_shutdown() exists is to prevent hang on shutdown
> when there are sessions that require reconnection and there is no way
> for it to succeed, because of iscsid is not running.
It should also really cleanup and disconnect from the SAN, which it
currently doesn't.
I've reproduced the hang you described on shutdown.
It should be noted that if there are outstanding writes we still see a
hang even with r286226.
I've posted a review https://reviews.freebsd.org/D4429, which I believe
achieves your goal as well as ensuring the sessions are closed before
reboot, so if we can take discussion there that would be great.
Hopefully it won't take to long to conclude, if however it does I'll
backout r291911 as on its own doesn't help.
Thanks for everyone's feedback, so far, its always appreciated :)
Regards
Steve
More information about the svn-src-head
mailing list