<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Unfortunately the Windows storage stack
does not recognize the unit attention code (capacity data has
changed) (at least it didn't in Server 2012) that could be used to
report a change in device capacity, so to get the system to rescan
the device to determine the capacity has changed a
BusChangedDetected needs to be reported.<br>
<br>
In my experience, SCSI RAID controller or HBA driver's don't do
anything to get the O/S to recognize the change which in turn
requires the user to manually disable and re-enable the device to
get Windows to recognize that the device's capacity has changed.
The NVMe driver is in the position to provide a better experience
that is consistent across hardware for all manufacturer's by
eliminating the need for manual user intervention.<br>
<br>
Jeff<br>
<br>
On 1/7/2014 8:44 AM, Luse, Paul E wrote:<br>
</div>
<blockquote
cite="mid:82C9F782B054C94B9FC04A331649C77A44748DB4@FMSMSX112.amr.corp.intel.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">Wrt Judy’s (a)
below, So I believe the original concern that drove us to
the implementation was that w/NVMe the block size can be
changed with a format whereas that can’t happen with a SCSI
format… I could be mistaken but on a quick scan of the email
threads I didn’t see that point mentioned. We felt like the
only way to get the upper layers to discover the potentially
changed block size was to tear it down/bring it back up<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thx<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Paul<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b>
<a class="moz-txt-link-abbreviated" href="mailto:nvmewin-bounces@lists.openfabrics.org">nvmewin-bounces@lists.openfabrics.org</a>
[<a class="moz-txt-link-freetext" href="mailto:nvmewin-bounces@lists.openfabrics.org">mailto:nvmewin-bounces@lists.openfabrics.org</a>]
<b>On Behalf Of </b>Neal Galbo (ngalbo)<br>
<b>Sent:</b> Tuesday, January 7, 2014 7:27 AM<br>
<b>To:</b> Mayes, Barrett N; Judy Brock-SSI;
<a class="moz-txt-link-abbreviated" href="mailto:nvmewin@lists.openfabrics.org">nvmewin@lists.openfabrics.org</a><br>
<b>Subject:</b> Re: [nvmewin] Handling IO when Format NVM
op is in progress<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">The conditions
you describe would never happen with a SCSI device. In
general, LU’s and LUN’s never disappear in SCSI; they are
not transient. They are not dynamic. They are static. They
either exist or they don’t. They don’t hide, once
enumerated/attached/located. Unlike namespaces.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">The media,
backing storage or provisioning can change, but the LU would
always be available for communication (commands). Other LU’s
in the same device would not be affected either – they are
independent entities relative to each other.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-Neal<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a moz-do-not-send="true"
href="mailto:nvmewin-bounces@lists.openfabrics.org">nvmewin-bounces@lists.openfabrics.org</a>
[<a moz-do-not-send="true"
href="mailto:nvmewin-bounces@lists.openfabrics.org">mailto:nvmewin-bounces@lists.openfabrics.org</a>]
<b>On Behalf Of </b>Mayes, Barrett N<br>
<b>Sent:</b> Tuesday, January 07, 2014 12:15 AM<br>
<b>To:</b> Judy Brock-SSI; <a moz-do-not-send="true"
href="mailto:nvmewin@lists.openfabrics.org">nvmewin@lists.openfabrics.org</a><br>
<b>Subject:</b> Re: [nvmewin] Handling IO when Format
NVM op is in progress<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">What problem do
you want to solve by keeping the block device around during
a format and allowing IO through so it can be failed with
check condition?
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Namespace not
ready can’t generically be translated to SCSI check
condition/not ready/Format In Progress. The driver would
need to know that a format command is outstanding so it
could translate that correctly (for 1.0-based device
support) since the namespace could be not ready for reasons
other than a format in progress. If the driver already has
to know a format is in progress, it could just fail commands
without sending it to the device (so no need for the new
failure code). But if that’s the case, why _<i>not</i>_
hide the LUN until the format is complete. By hiding the
LUN and bringing it back when the format is complete, you
don’t have to worry about handling IO and you also take care
of the re-enumeration that has to happen when the format is
complete (in the case of changing the LBA Format).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-Barrett<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> <a moz-do-not-send="true"
href="mailto:nvmewin-bounces@lists.openfabrics.org">
nvmewin-bounces@lists.openfabrics.org</a> [<a
moz-do-not-send="true"
href="mailto:nvmewin-bounces@lists.openfabrics.org">mailto:nvmewin-bounces@lists.openfabrics.org</a>]
<b>On Behalf Of </b>Judy Brock-SSI<br>
<b>Sent:</b> Monday, January 06, 2014 8:09 PM<br>
<b>To:</b> <a moz-do-not-send="true"
href="mailto:nvmewin@lists.openfabrics.org">nvmewin@lists.openfabrics.org</a><br>
<b>Subject:</b> [nvmewin] Handling IO when Format NVM op
is in progress<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">All,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Many months ago, I initiated a thread (see
attached) in which I argued that there were some holes in the
current implementation of Format NVM ioctl passthru and in
which I advocated for, among other things, the addition of
logic to make sure pseudo-SCSI bus re-enumeration had fully
taken place in the driver (such that Storport was notified
that no “luns” were present) before the actual Format NVM op
was launched.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I intuitively understand – and up to this
point have unquestioningly agreed with – the basic assumption
that the reason the namespaces must be removed/ “luns”
disappeared prior to formatting is because “<span
style="font-size:10.0pt;color:#1F497D">we cannot format a
namespace while the OS is aware of its presence and could be
potentially sending I/O to a stale namespace config (i.e.
changing LBA/sector size).</span>” (excerpt from attached
thread).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The question has recently arisen in
internal discussion however as to whether or not we really
have to do this. It was pointed out that SCSI devices (real
ones) are capable of receiving IO commands while SCSI format
commands are in process. They will return the following error:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> SCSI status = Check condition,
sense code = NOT READY (0x2), additional sense code = LUN NOT
READY (0x4), additional sense code qualifier = FORMAT IN
PROGRESS (0x4)<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Why then, instead of removing
namespaces/luns, can our Windows driver not return the same
error status a real SCSI drive would return in such a
situation? One would assume that upper layers of the storage
stack have plenty years of experience in knowing what to do
when it sees that error. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">As a point of comparison, there is no
standard I am aware of which specifies that Storport miniports
which support real SCSI devices, if they happen to provide a
proprietary pass-thru to allow a SCSI format command to go
through to a device, must cause all LUNS to appear offline
prior to formatting,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">One could even argue (and they have!) that
these IO commands could even be allowed to go through to the
NVMe device itself (as in the real SCSI case); NVMe 1.1
Technical Proposal 005 has defined a new format-in-progress
status code that NVMe firmware will be able to return at some
point in the future, current firmware could easily return
NAMESPACE_NOT_READY and driver could translate to the above
SCSI sense data, etc.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So … here I stand, devil’s advocate hat in
hand, hoping to find out:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in">a)<span
style="font-size:7.0pt;font-family:"Times New
Roman","serif"">
</span> what the “back story” is on how this decision was
ultimately made (the attached thread said a lot of discussion
took place on the subject)<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in">b)<span
style="font-size:7.0pt;font-family:"Times New
Roman","serif"">
</span> whether or not the diametrically-opposed alternative I
am discussing above was thoroughly considered and if so, why
it was rejected<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in">c)<span
style="font-size:7.0pt;font-family:"Times New
Roman","serif"">
</span> whether the topic bears reconsidering at this point.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks in advance for your collective
consideration,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Judy<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
nvmewin mailing list
<a class="moz-txt-link-abbreviated" href="mailto:nvmewin@lists.openfabrics.org">nvmewin@lists.openfabrics.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin">http://lists.openfabrics.org/cgi-bin/mailman/listinfo/nvmewin</a>
</pre>
</blockquote>
<br>
</body>
</html>