Cersions and web updated
[mirror/scst/.git] / www / mc_s.html
1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">\r
2 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">\r
3 <head>\r
4 <meta name="Keywords" content="Generic SCSI Target Middle Level 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">SCSI Target Middle Level for Linux</h2> \r
18         </div>          \r
19                 \r
20         <div id="menu">\r
21                 <ul>\r
22                         <li id="sponsorship"><a href="sponsorship.html">Sponsorship</a></li>
23                         <li><a href="index.html">Home</a></li>
24                         <li><a href="http://www.sourceforge.net/projects/scst">Main/News</a></li>\r
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.</li></span>
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.</li></span>
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 tape
140 backup and restore. Both MC/S and MPIO work on the commands level, so
141 can't split data transfers for a single command over several links. Only
142 bonding can improve performance in this case, because it works on the
143 link level.</p>
144
145 <p>MC/S over several links preserves commands execution order, i.e. with
146 it commands executed in the same order as they were submitted. MPIO
147 can't preserve this order, because it can't see, which command on which
148 link was submitted earlier. Delays in links processing can change
149 commands order in the place where target receives them.</p>
150
151 <p>Since initiators usually send commands in the optimal for performance
152 order, reordering can somehow hurt performance. But this can happen only with
153 naive target implementation, which can't recover the optimal commands execution
154 order. Currently Linux is not naive and quite good on this area. See, for
155 instance, section "SEQUENTIAL ACCESS OVER MPIO" in <a
156 href="vl_res.txt">those measurements</a>. Don't look at the absolute
157 numbers, look at %% of performance improvement using the second link.
158 The result equivalent to 200 MB/s over 2 1Gbps links, which is close to
159 possible maximum.</p>
160
161 <p>If free commands reorder is forbidden for a device, either
162 by use of ORDERED tag, or if the Queue Algorithm Modifier in the Control
163 Mode Page is set to 0, then MPIO will have to maintain commands order by
164 sending commands over only a single link. But on practice this case is
165 really rare and 99.(9)% of OS'es and applications allow free commands
166 reorder and it is enabled by default.</p>
167
168 <p>From other side, strictly preserving commands order as MC/S does has a
169 downside as well. It can lead to so called "commands ordering
170 bottleneck", when newer commands have to wait before one or more older
171 commands get executed, although it would be better for performance to
172 reorder them. As result, MPIO sometimes has better performance, than
173 MC/S, especially in setups, where maximum IOPS number is important. See,
174 for instance,
175
176 <a href="http://article.gmane.org/gmane.linux.scsi/16311">http://article.gmane.org/gmane.linux.scsi/16311</a>.
177 </p>
178
179 <h2>Conclusion</h2>
180
181 <p>Thus:</p>
182
183 <ol>
184         <li><span>Benefits of MC/S are marginal and with future MPIO
185         improvements can be made negligible.</span></li>
186
187         <li><span>MPIO allows to utilize existing infrastructure for all
188         transports, not only iSCSI.
189          </span></li>
190         
191         <li><span>All transports can benefit from improvements in MPIO.</span></li>
192
193         <li><span>With MPIO there is no need to create multiple layers doing very similar
194         functionality.</span></li>
195
196         <li><span> MPIO doesn't have commands ordering bottleneck, which MC/S has. </span></li>
197
198 </ol>
199
200 <p>Hence, what's the point to implement MC/S, which is a very tricky
201 task? Better to spend this effort on improving MPIO. Simply, MC/S is
202 done on the wrong level. No surprise then that no Open Source OS'es
203 neither support, nor going to implement it. Moreover, when back to 2005
204 there was an attempt to add MC/S in Linux, it was rejected. See for more details
205 <a href="http://article.gmane.org/gmane.linux.scsi/15769">http://article.gmane.org/gmane.linux.scsi/15769</a>
206 and <a href="http://article.gmane.org/gmane.linux.scsi/16301">http://article.gmane.org/gmane.linux.scsi/16301</a>.
207 </p>
208
209 <p>But for sake of completeness, there are marginal cases, where MPIO
210 can't be used or will not provide any benefit, but MC/S can be successful:</p>
211
212 <ol>
213         <li><span>When strict commands order is required.</span></li>
214
215         <li><span>When aborted commands can't be retried.</span></li>
216
217 </ol>
218
219 <p>For disks both of them are always false. However for some tape drives
220 and backup applications one or both can be true. But on practice:</p>
221
222 <ul>
223
224         <li><span>There are neither known tape drives, nor backup
225         applications, which can use multiple outstanding commands at
226         time. All them support and use only one single outstanding
227         command at time. MC/S can't increase performance for them, only
228         bonding can. So, in this case there no difference between MC/S
229         and MPIO.</span></li>
230
231         <li><span>The lack of ability to retry commands is rather a
232         limitation of legacy tape drives, which support only implicit
233         address commands, not of MPIO. Modern tape drives and backup
234         applications can use explicit address commands, which you can
235         abort and then retry, hence they are compatible with MPIO.</span></li>
236
237 </ul>
238
239 <p>If in future SCSI standards gain possibility to group several I_T nexuses
240 with possibilities to reassign commands between them and 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>\r
251                         &copy; Copyright 2008-2009 <b><font color="#EC981F">Vladislav Bolkhovitin & others.</font>&nbsp;&nbsp;\r
252                         Design by: <b><font color="#EC981F">Daniel Fernandes</font></b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;         \r
253                         \r
254                         </p>            \r
255                 </div>  \r
256 <!-- footer ends here -->\r
257 </body>\r
258
259 <!-- Piwik -->
260 <script type="text/javascript">
261 var pkBaseURL = (("https:" == document.location.protocol) ? "https://apps.sourceforge.net/piwik/scst/" : "http://apps.sourceforge.net/piwik/scst/");
262 document.write(unescape("%3Cscript src='" + pkBaseURL + "piwik.js' type='text/javascript'%3E%3C/script%3E"));
263 </script><script type="text/javascript">
264 piwik_action_name = '';
265 piwik_idsite = 1;
266 piwik_url = pkBaseURL + "piwik.php";
267 piwik_log(piwik_action_name, piwik_idsite, piwik_url);
268 </script>
269 <object><noscript><p><img src="http://apps.sourceforge.net/piwik/scst/piwik.php?idsite=1" alt="piwik"/></p></noscript></object>
270 <!-- End Piwik Tag -->
271
272 </html>