Reloading iscsi target, iscsi initiator panics

[Edward Tomasz Napierała]

On 1018T2321, Frank de Bot (lists) wrote:
> Frank de Bot wrote:
> > Edward Tomasz Napierała wrote:
> >> On 1015T2005, Frank de Bot (lists) wrote:
> >>> Edward Tomasz Napierała wrote:
> >>>> On 1014T2316, Frank de Bot (lists) wrote:
> >>>>> Hello,
> >>>>>
> >>>>> I have a FreeBSD 10.2 server running as iSCSI target. Another FreeBSD
> >>>>> 10.2 is an initiator and has several targets used.
> >>>>>
> >>>>> When I add a target and reload its config with 'service ctld reload',
> >>>>> the FreeBSD initiator server panics. It's reproducable (I have a
> >>>>> coredump, but I think it's clear what the problem is)
> >>>>
> >>>> How easy it is to reproduce, eg. does it happen about every time?
> >>>> Could you paste the backtrace?
> >>>
> >>> The first time I didn't understand what happened, the second time I
> >>> could relate it directly to the reloading of ctld on the iSCSI, within
> >>> moments the server paniced.
> >>>
> >>> I got 2 backtraces:
> >>>
> >>> First one:
> >>>
> >>> Fatal trap 12: page fault while in kernel mode
> >>> cpuid = 1; softdep_deallocate_dependencies: got error 6 while accessing
> >>
> >> This is the FFS on the initiator side panicing because the device it's
> >> on went away.  The softupdates code can't handle that very well.
> >>
> >> I have no idea why the devices went away and then reappeared, as visible
> >> in the logs.  What has the changed in the ctl.conf?  Do you have any
> >> iscsi-related sysctls set on the initiator side?
> >>
> > 
> > I've added a new target in the ctl.conf . On the linux server I also see
> > a brief disconnect,  but a reconnect is handled well.
> > 
> > I haven't set any sysctl's related to iscsi
> > 
> > My ctl.conf is (again anonymized):
> > 
> > auth-group my-auth {
> >         chap "myiscsi" "verysecret"
> > }
> > portal-group pg0 {
> >         discovery-auth-group my-auth
> >         listen 10.13.37.2
> > }
> > 
> > target iqn.2015-03.lan.my.nas:vmstorage-29 {
> >         auth-group my-auth
> >         portal-group pg0
> >         lun 0 {
> >                 path /tank/images/iscsi/vmstorage-29/vmstorage-29.img
> >                 size 20484M
> >                 blocksize 4096
> >                 option unmap on
> >         }
> > }
> > 
> > target iqn.2015-03.lan.my.nas:vmstorage-44 {
> >         auth-group my-auth
> >         portal-group pg0
> >         lun 0 {
> >                 path /tank/images/iscsi/vmstorage-44/vmstorage-44.img
> >                 size 102404M
> >                 blocksize 4096
> >                 option unmap on
> >         }
> > }
> > 
> > target iqn.2015-03.lan.my.nas:keyserver.my.nl {
> >         auth-group my-auth
> >         portal-group pg0
> >         lun 0 {
> >                 path /dev/zvol/tank/hosting_images/keyserver.my.nl
> >                 blocksize 4096
> >                 option unmap on
> >         }
> > }
> > 
> > the vmstorage-44 is last added to the config
> > 
> 
> I've started up my test environment, but I could not reproduce is there.
> When reloading the target, a
> SCSI sense: UNIT ATTENTION asc:3f,e (Reported LUNs data has changed) is
> reported, but no device is destroyed. All servers are running the same
> kernel and userland 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666
> 
> What can those device disconnects cause?

Well, that's the thing: ctld was written to make really, really sure
that reloading configuration does not affect LUNs and targets which
hadn't changed.  So, to be honest - no idea.  Are you sure you didn't
restart (as in, stop and then start again) ctld instead of reloading
its configuration?