Web fixes from Daniel Fernandes <dfernandes1978@hotmail.com>
[mirror/scst/.git] / www / mc_s.html
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">\r
2 <html>\r
3 <head>\r
4 <meta name="Keywords" content="Generic SCSI Target Subsystem for Linux, iSCSI target, MC/S, multiple connections per session">\r
5 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">\r
6 <meta name="author" content="Daniel Fernandes">\r
7 <meta name="Robots" content="index,follow">\r
8 <link rel="stylesheet" href="images/Orange.css" type="text/css">        \r
9 <title>MC/S vs MPIO</title>\r
10 </head>\r
11 \r
12 <body>\r
13 <!-- wrap starts here -->\r
14 <div id="wrap"> \r
15         <div id="header">       \r
16                 <div class="logoimg"></div><h1 id="logo"><span class="orange"></span></h1>\r
17                 <h2 id=slogan>Generic SCSI Target Subsystem for Linux</h2>      \r
18         </div>          \r
19                 \r
20         <div id="menu">\r
21                 <ul>\r
22                         <li><a href="index.html">Home</a></li>
23                         <li><a href="http://www.sourceforge.net/projects/scst">Main</a></li>\r
24                         <li><a href="http://sourceforge.net/news/?group_id=110471">News</a></li>
25                         <li><a href="targets.html">Drivers</a></li>\r
26                         <li><a href="downloads.html">Downloads</a></li>\r
27                         <li><a href="contributing.html">Contributing</a></li>\r
28                         <li id="current"><a href="comparison.html">Comparison</a></li>          \r
29                 </ul>\r
30         </div>\r
31         \r
32         <!-- content-wrap starts here -->       \r
33         <div id="content-wrap">  \r
34                         <div id="sidebar">\r
35                                 <h1>Comparison</h1>\r
36                                 <ul class="sidemenu">
37                                         <li><a href="comparison.html">Features comparison</a></li>
38                                         <li><a href="scstvsstgt.html">SCST vs STGT</a></li>
39                                         <li><a href="mc_s.html">MC/S vs MPIO</a></li>
40                                 </ul>
41                         </div>          \r
42         
43                         <div id="main">
44
45 <h1>MC/S vs MPIO</h1>
46
47 <p>MC/S (Multiple Connections per Session) is a feature of iSCSI
48 protocol, which allows to combine several connections inside a single
49 session for performance and failover purposes. Let's consider what
50 practical value this feature has comparing with OS level multipath
51 (MPIO) and try to answer why none of Open Source OS'es neither still
52 support it, despite of many years since iSCSI protocol started
53 being actively used, nor going to implement it in the future.</p>
54
55 <p> MC/S is done on the iSCSI level, while MPIO is done on the higher
56 level. Hence, all MPIO infrastructure is shared among all SCSI
57 transports, including Fibre Channel, SAS, etc. </p>
58
59 <p> MC/S was designed at time, when most OS'es didn't have standard OS level
60 multipath. Instead, each vendor had its own implementation, which
61 created huge interoperability problems. So, one of the goals of MC/S was
62 to address this issue and standardize the multipath area. But
63 nowadays almost all OS'es has OS level multipath implemented using
64 standard SCSI facilities, hence this purpose of MC/S isn't valid anymore.</p>
65
66 <p>Usually it is claimed, than MC/S has the following 2 advantages over MPIO:</p>
67
68 <ol>
69         <li><span>Faster failover recovery.</span></li>
70
71         <li><span>Better performance.</span></li>
72
73 </ol>
74
75 <p>Let's look how much true those claims are.</p>
76
77 <h2>Failover recovery time</h2>
78
79 <p>Let's consider a single target exporting a single device over 2 links.</p>
80
81 <p>For MC/S failover recovery is pretty simple: all outstanding SCSI
82 commands reassigned to another connection. No other actions are
83 necessary, because session (i.e. I_T Nexus) remains the same.
84 Consequently, all reservations and other SCSI states as well as other
85 initiators connected to the device remain unaffected.</p>
86
87 <p>For MPIO failover recovery is much more complicated. This is because
88 it involves transfer of all outstanding commands and SCSI states from one
89 I_T Nexus to another. The first thing, which initiator will do for
90 that is to abort all outstanding commands on the faulted
91 I_T Nexus. There are 2 approaches for that: CLEAR TASK SET and LUN RESET
92 task management functions. </p>
93
94 <p>CLEAR TASK SET function aborts all commands on the device.
95 Unfortunately, it has limitations: it isn't always supported by device
96 and having single task set shared over initiators isn't always
97 appropriate for application.</p>
98
99 <p>LUN RESET function resets the device.</p>
100
101 <p>Both CLEAR TASK SET and LUN RESET functions can somehow harm
102 other initiators, because all commands from all initiators, not only 
103 from one doing the failover recovery, will be aborted. Additionally, LUN
104 RESET resets all SCSI settings for all connected initiators to the
105 initial state and, if device had reservation from any initiator, it will
106 be cleared.
107
108 <p>But the harm is minimal:</p>
109
110 <ul>
111         <li><span> With TAS bit set on Control Mode page, all the aborted commands will
112         be returned to all affected initiators with TASK ABORTED status, so they
113         can simply immediately retry them. For CLEAR TASK SET if TAS isn't set
114         all affected initiators will be notified by Unit Attention COMMANDS
115         CLEARED BY ANOTHER INITIATOR, so they also can immediately retry all
116         outstanding commands.</span></li>
117
118         <li><span>In case of device reset the affected initiators will be notified via
119         the corresponding Unit Attention about the device reset, i.e. about reset of
120         all SCSI settings to the initial state. Then they can do the necessary
121         recovery actions. Usually no recovery actions are needed, except for the
122         reservation holder, whose reservation was cleared. For it recovery might
123         be not trivial. But Persistent Reservations solve this issue, because
124         they are not cleared by the device reset.</span></li>
125 </ul>
126
127 <p>Thus, with Persistent Reservations or using  CLEAR TASK SET function
128 additional failover recovery time, which MPIO has comparing to MC/S,
129 is time to wait for reset or commands abort finished and time to
130 retry all the aborted commands. On a properly configured system it
131 should be less than few seconds, which is well acceptable on practice.
132 If Linux storage stack improved to allow to abort all submitted to it
133 commands (currently only wait for their completion is possible), then
134 time to abort all the commands can be decreased to a fraction of second. </p>
135
136 <h2>Performance</h2>
137
138 <p>At first, neither MC/S, nor MPIO can improve performance if there is
139 only one SCSI command sent to target at time. For instance, in case of
140 tape backup and restore. Both MC/S and MPIO work on the commands level,
141 so can't split data transfers for a single command over several links.
142 Only bonding (also known as NIC teaming or Link Aggregation) can improve
143 performance in this case, although also with limitations, because it
144 works on the link level.</p>
145
146 <p>MC/S over several links preserves commands execution order, i.e. with
147 it commands executed in the same order as they were submitted. MPIO
148 can't preserve this order, because it can't see, which command on which
149 link was submitted earlier. Delays in links processing can change
150 commands order in the place where target receives them.</p>
151
152 <p>Since initiators usually send commands in the optimal for performance
153 order, reordering can somehow hurt performance. But this can happen only with
154 naive target implementation, which can't recover the optimal commands execution
155 order. Currently Linux is not naive and quite good on this area. See, for
156 instance, section "SEQUENTIAL ACCESS OVER MPIO" in <a
157 href="vl_res.txt">those measurements</a>. Don't look at the absolute
158 numbers, look at %% of performance improvement using the second link.
159 The result equivalent to 200 MB/s over 2 1Gbps links, which is close to
160 possible maximum.</p>
161
162 <p>If free commands reorder is forbidden for a device, either
163 by use of ORDERED tag, or if the Queue Algorithm Modifier in the Control
164 Mode Page is set to 0, then MPIO will have to maintain commands order by
165 sending commands over only a single link. But on practice this case is
166 really rare and 99.(9)% of OS'es and applications allow free commands
167 reorder and it is enabled by default.</p>
168
169 <p>From other side, strictly preserving commands order as MC/S does has a
170 downside as well. It can lead to so called "commands ordering
171 bottleneck", when newer commands have to wait before one or more older
172 commands get executed, although it would be better for performance to
173 reorder them. As result, MPIO sometimes has better performance, than
174 MC/S, especially in setups, where maximum IOPS number is important. See,
175 for instance,
176 <a href="http://article.gmane.org/gmane.linux.scsi/16311">here</a>.
177 </p>
178
179 <h2>When MC/S is better than MPIO</h2>
180
181 <p>There are marginal cases, where MPIO can't be used or will not
182 provide any benefit, but MC/S can be successful:</p>
183
184 <ol>
185         <li><span>When strict commands order is required.</span></li>
186
187         <li><span>When aborted commands can't be retried.</span></li>
188
189 </ol>
190
191 <p>For disks both of them are always false. However for some tape drives
192 and backup applications one or both can be true. But on practice:</p>
193
194 <ul>
195
196         <li><span>There are neither known tape drives, nor backup
197         applications, which can use multiple outstanding commands at
198         time. All them support and use only one single outstanding
199         command at time. MC/S can't increase performance for them, only
200         bonding can. So, in this case there no difference between MC/S
201         and MPIO.</span></li>
202
203         <li><span>The lack of ability to retry commands is rather a
204         limitation of legacy tape drives, which support only implicit
205         address commands, not of MPIO. Modern tape drives and backup
206         applications can use explicit address commands, which you can
207         abort and then retry, hence they are compatible with MPIO.</span></li>
208
209 </ul>
210
211 <h2>Conclusion</h2>
212
213 <p>Thus:</p>
214
215 <ol>
216         <li><span>Cost to develop MC/S is high, but benefits of it are marginal and with future MPIO
217         improvements can be made negligible.</span></li>
218
219         <li><span>MPIO allows to utilize existing infrastructure for all
220         transports, not only iSCSI.
221          </span></li>
222         
223         <li><span>All transports can benefit from improvements in MPIO.</span></li>
224
225         <li><span>With MPIO there is no need to create multiple layers doing very similar
226         functionality.</span></li>
227
228         <li><span> MPIO doesn't have commands ordering bottleneck, which MC/S has. </span></li>
229
230 </ol>
231
232 <p> Simply, MC/S is done on the wrong level. No surprise then that no
233 Open Source OS'es neither support, nor going to implement it. Moreover,
234 when back to 2005 there was an attempt to add MC/S in Linux, it was
235 rejected. See for more details <a href="http://article.gmane.org/gmane.linux.scsi/15769">here</a>
236 and <a href="http://article.gmane.org/gmane.linux.scsi/16301">here</a>.
237 </p>
238
239 <p>If in future SCSI standards gain possibility to group several I_T nexuses
240 with ability to reassign commands between them as well as preserve commands
241 order among them, the above minor advantages of MC/S over MPIO will be
242 removed and, hence, all investments in it will be voided.</p>
243
244                         </div> \r
245         </div>\r
246 </div>          \r
247 <!-- wrap ends here -->\r\r
248 <!-- footer starts here -->             \r
249 <div id="footer">\r
250         <p>&copy; Copyright 2004-2009 <b><font color="#EC981F">Vladislav Bolkhovitin &amp others.</font></b>&nbsp;&nbsp;\r
251            Design by: <b><font color="#EC981F">Daniel Fernandes</font></b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</p>          \r
252 </div>  \r
253 <!-- footer ends here -->\r
254 <!-- Piwik -->
255 <script type="text/javascript">
256 var pkBaseURL = (("https:" == document.location.protocol) ? "https://apps.sourceforge.net/piwik/scst/" : "http://apps.sourceforge.net/piwik/scst/");
257 document.write(unescape("%3Cscript src='" + pkBaseURL + "piwik.js' type='text/javascript'%3E%3C/script%3E"));
258 </script><script type="text/javascript">
259 piwik_action_name = '';
260 piwik_idsite = 1;
261 piwik_url = pkBaseURL + "piwik.php";
262 piwik_log(piwik_action_name, piwik_idsite, piwik_url);
263 </script>
264 <object><noscript><p><img src="http://apps.sourceforge.net/piwik/scst/piwik.php?idsite=1" alt="piwik"></p></noscript></object>
265 <!-- End Piwik Tag -->
266 </body>
267 </html>