[Bug 819674] New: IO throttle on one LUN by target QoS Setting causes other LUNs to be throttled as well
https://bugzilla.novell.com/show_bug.cgi?id=819674 https://bugzilla.novell.com/show_bug.cgi?id=819674#c0 Summary: IO throttle on one LUN by target QoS Setting causes other LUNs to be throttled as well Classification: openSUSE Product: openSUSE 11.4 Version: Final Platform: x86-64 OS/Version: SLES 10 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers@forge.provo.novell.com ReportedBy: dinesh.surpur@hp.com QAContact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0 Operating Sytem : SLES 10.4 Component : open iSCSI Software initiator We implemented QOS on 3PAR Target array side where you can place settings on the target side which will determine how many I/O (IOPS) or BW (Bandwidth) a given set of LUNs which we call a VVSET a target side allows at any given point of time. What we have seen is that if we limit IOPS on one set of LUNs and there is a second set of different LUNs to the same host are also getting impacted (IOPS or BW) even though there are no bandwidth or qos limit settings Simple example you have LUN 1 and LUN 2 to a given host and both are doing 5000 IOPS each. Now you limit on the target side LUN 1 can allow only 1000 IOPS at any given point of time by artificially increasing the Service times we see that LUN 2 is also effected where the number of IOPS from the host drop to 1000 as well even through there is no limit set. This issue does not occur if we using Fibre Channel connectivity occurs only with iSCSI SW initiator. Essentially it seems that SW iSCSI we cannot limit IO’s per LUN basis and effects other LUNs as well. Reproducible: Always Steps to Reproduce: 1. Connect iSCSI host to 3PAR Target running firmware 3.1.2.MU2 code 2. Export 10 LUNs from storage to host and do discover devices and are added to host multipathing software (DM) 3. Run IO tool to the 10 LUNs example we use snaptest an internal I/O tool 4. Measure the IOPs happening say ex: 5000 IOPS to the first 5 LUNs and 5000 IOPS to the LUNs 6-10 5. Apply Qos rule to target side so that the first 5 LUNs can do only 1000 IOPs 6. Measure the throughput we see that the first 5 LUNs the IOPS is 1000 but also for LUNs 6-10 the IOPs is also 1000 as well (reduced even through there is no Qos Rule for LUNs 6-10) 7. The problem were other LUNs are impacted is seen on s/w iSCSI and not on FC connectivity. Actual Results: --Mentioned in steps above Expected Results: --Mentioned in steps above -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com