#Trident ISCSI multipath.conf Ubuntu 24.04.

1 messages · Page 1 of 1 (latest)

dire sigil
#

In the Trident documentation, it says that the multipath configuration for Ubuntu should look like this:

defaults {
user_friendly_names yes
find_multipaths no
}

If I understand correctly, the priority is currently set to:

1167270.297209 | sdd: prio = sysfs (setting: storage device autodetected)

and not to "ontap". Shouldn't it be set to "ontap"? I suspect that the multipath settings are not being applied correctly — could that be the case?

Here are some relevant logs:

3600a098038314976613f59456652377a dm-6 NETAPP,LUN C-Mode
size=100G features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| - 34:0:0:1 sdc 8:32 active ready running -+- policy='service-time 0' prio=10 status=enabled
`- 35:0:0:1 sdd 8:48 active ready running

1167270.276085 | sdc: size = 209715200
1167270.276608 | sdc: vendor = NETAPP
1167270.276696 | sdc: product = LUN C-Mode
1167270.276777 | sdc: rev = 9151
1167270.277333 | sdc: h🅱️t:l = 34:0:0:1
1167270.278511 | sdc: tgt_node_name = iqn.1992-08.com.netapp:sn.d91044b5271f11f0894dd039ea952238:vs.25
1167270.278598 | sdc: uid_attribute = ID_SERIAL (setting: multipath internal)
1167270.278625 | sdc: recheck_wwid = 1 (setting: multipath.conf defaults/devices section)
1167270.278903 | sdc: 13054 cyl, 255 heads, 63 sectors/track, start at 0
1167270.278938 | sdc: vpd_vendor_id = 0 "undef" (setting: multipath internal)
1167270.279018 | sdc: serial = 81Iva?YEfR7z
1167270.279048 | sdc: detect_checker = yes (setting: multipath internal)
1167270.280249 | sdc: path_checker = tur (setting: storage device autodetected)
1167270.280286 | sdc: checker timeout = 30 s (setting: kernel sysfs)
1167270.280722 | sdc: tur state = up

We are searching why we have on nfs the 700 MB/s and why we have on iscsi only 330 MB/s.

rustic merlin
#

You can add prio and see if it helps performance. The value listed in trident documentation are values it requires.

left sigil
#

"hwhandler alua" is correct, the "ontap" one you refer ti was in old 7G where there was no ALUA yet. Changing prio won't help as it will only ever write to sdc due to ALUA. Try adding a second LIF per node maybe? 330 vs 700 mb/s sounds really dubious there must be something wrong there

teal flame
dire sigil
#

I added 2 ISCSI Interface i got the same result.

timestamp,device,mountpoint,test_type,bw_MBps,iops,lat_us_avg,duration_s
2025-10-29 08:21:36,/dev/mapper/3600a0980383149763524587242424542,/mnt,seq_write,455.44,116593.480217,32,30
2025-10-29 08:21:36,/dev/mapper/3600a0980383149763524587242424542,/mnt,seq_read,266.39,68196.026799,48,31
2025-10-29 08:21:36,/dev/mapper/3600a0980383149763524587242424542,/mnt,rand_write,292.33,74836.307060,809,35
2025-10-29 08:21:36,/dev/mapper/3600a0980383149763524587242424542,/mnt,rand_read,6.24,1598.280057,40011,31

Only 6.2 MB/s

So rand_read are fio with 4K Blocksize iodepth 64 an 1 job.
The reason for this is , that we are migration from pure at the moment and that is the testcase.

dire sigil
#

Our Messagement is with ./kubestr fio -s <storageclass>

StorageClass,JobName,Blocksize,RW,IOPS,Bandwidth_KiBs
pure,read_iops,4K,randread,22436.912109,89764
pure,write_iops,4K,randwrite,19794.134766,79193
pure,read_bw,128K,randread,20346.951172,2604947
pure,write_bw,128K,randwrite,17807.105469,2279846
netapp,read_iops,4K,randread,6208.430664,24850
netapp,write_iops,4K,randwrite,5546.646973,22203
netapp,read_bw,128K,randread,4588.854004,587910
netapp,write_bw,128K,randwrite,4479.619141,573928

Question :

I honestly don’t care how fast Pure is here; I have to switch to NetApp. My concern is more about interpreting the values. Are the values for NetApp acceptable, or is there a fundamental problem?