Bug or Feature: Shared Block Drives Listed in Storage->Disks

[sfcredfox]

Updated to version: (Core) TrueNAS-13.0-U5.3

Started getting SMART errors that I never had before.
Device: /dev/da50, failed to read SMART values.

Looked further:
Four listed drives are my iSCSI/FC extents. The disk sizes and serial numbers match. See picture.

Is it a bug, feature, or misconfiguration that the iSCSI disks are now showing up in the 'Storage->Disks' list? I have excluded them from SMART test task, but the smart alert is every day.

I've never had this before the upgrade.

I could look into restricting the iSCSI initiators group if it's doing some weird loop back discovery?

I included screen shot of tunables for iSCSI/FC and script for ctl start bug.

SMART Error:

Storage->Disks:

Block Shares: (notice the serial numbers)

Customization:

 

[HoneyBadger]

I see you have the isp driver hints in to set the default role as "0/none" - but if something in the firmware changed it might be necessary to explicitly set them as target.

What version were you on prior to U5.3 - U4?

 

[sfcredfox]

What version were you on prior to U5.3 - U4?

I shouldn't have deleted the boot environment already I guess. I think it was U5.2?

isp driver hints

Ah. I didn't think about that since it always just 'worked'.

I hate FreeBSD documentation so much. It says:

hint.isp.0.role
A hint to define default role for isp instance (target, initia-
tor, both).

There is no mention of 0,1,2. I have also seen people write:

hint.isp.0.role ="target"

The good 'ol guides on the forum set it as 0. Not sure why since I can't find a table anywhere that specifies which is which.

Any ideas?

** Edit/Update**
I found this:

isp(4freebsd) — freebsd-manpages — Debian stretch — Debian Manpages

hint.isp.0.roleA hint to define default role for isp instance (0 -- none, 1 -- target, 2 -- initiator, 3 -- both).

Annoying I can't seem to find it for FBSD. I'm probably not Googling right...

What ever, going to try changing the setting next reboot and see what happens.

 

[HoneyBadger]

isp(4)

man.freebsd.org

hint.isp.N.role - A hint to define default role for isp instance (0 -- none, 1 -- target, 2 -- initiator, 3 -- both).

Got you covered. Should be 1 for your setup, but I haven't messed with it in some time.

 

[sfcredfox]

isp(4)

man.freebsd.org

Got you covered. Should be 1 for your setup, but I haven't messed with it in some time.

@HoneyBadger Well, you're a badass of sorts. Good call. It was indeed some kind of behavior change regarding the ISP/CTL mode.

Even though the tune was set for hint.isp.0.role=0, it was in 3 in the back ground.

Code:

root@carm-san:~ # sysctl dev.isp.0.role=1
dev.isp.0.role: 3 -> 1

Then did:

Code:

root@carm-san:~ #  ctladm port -p 3 -o off
Front End Ports disabled
root@carm-san:~ # ctladm port -p 3 -o on
Front End Ports enabled

Eliminated the redundant disks. The system console showed:

Code:

GEOM_MULTIPATH: da45 removed from disk1
(da47:isp0:0:2:17): Periph destroyed

I did the ports one by one, and then the disks were gone.
This made me want to look at the zoning also. I might have added both ports to a zone, meaning it could talk to itself. I'll get into the fabric switch next.

Thanks again.

 

[HoneyBadger]

@HoneyBadger Well, you're a badass of sorts. Good call. It was indeed some kind of behavior change regarding the ISP/CTL mode.

Even though the tune was set for hint.isp.0.role=0, it was in 3 in the back ground.

Awesome. I'll take it back to Engineering, see if we can make this happen on an FC unit here.

This made me want to look at the zoning also. I might have added both ports to a zone, meaning it could talk to itself. I'll get into the fabric switch next.

Single-initiator/multi-target is a valid config, not as optimal as single-init/single-target though, but easier to manage. Your SAN might have a "wizard" or some other internal functionality that lets you write your zones as SI/MT but translates them to SI/ST before actually applying them.

But definitely don't want to bridge two separate sides of your SAN. Make two sides and channel your inner Gandalf for traffic management - YOU SHALL NOT PASS (frames between two separate SANs)

 

[sfcredfox]

don't want to bridge two separate sides of your SAN

I went and looked at the zone config. It was SI/MT.

Probably need to switch to MI/ST to have two zones instead of four per host. No wizard in ancient equipment, just CLI.

I get mixed thoughts on braiding the two fabrics for both iSCSI and FC(oE). Some say don't, some say do. I guess its more essential if you are on a single controller system, like core instead of scale/cluster.

 

[HoneyBadger]

I went and looked at the zone config. It was SI/MT.

Probably need to switch to MI/ST to have two zones instead of four per host. No wizard in ancient equipment, just CLI.

I get mixed thoughts on braiding the two fabrics for both iSCSI and FC(oE). Some say don't, some say do. I guess its more essential if you are on a single controller system, like core instead of scale/cluster.

The default old-school FC admin in me says "single-initiator" - multi-anything means more SCRs (state change requests) every time an init or target goes offline/reboots, and better to keep that limited. I'd grit my teeth and probably script out the CLI functions to bang out the zones as SI/ST.