<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@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:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","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;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi, From what I understand this does not affect FC SAN cluster configuration, but mostly NSD IO communication?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal">Tomasz Wolski<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<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""> gpfsug-discuss-bounces@spectrumscale.org [mailto:gpfsug-discuss-bounces@spectrumscale.org]
<b>On Behalf Of </b>Ben De Luca<br>
<b>Sent:</b> Wednesday, October 11, 2017 6:40 AM<br>
<b>To:</b> gpfsug main discussion list<br>
<b>Subject:</b> Re: [gpfsug-discuss] FW: [EXTERNAL] FLASH: IBM Spectrum Scale (GPFS) V4.1 and 4.2 levels: network reconnect function may result in file system corruption or undetected file data corruption (2017.10.09)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Lyle thanks for the update, has this issue always existed, or just in v4.1 and 4.2?<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It seems that the likely hood of this event is very low but of course you encourage people to update asap. <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 11 October 2017 at 00:15, Uwe Falke <<a href="mailto:UWEFALKE@de.ibm.com" target="_blank">UWEFALKE@de.ibm.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi, I understood the  failure to occur requires that the RPC payload of<br>
the RPC resent without actual header can be mistaken for a valid RPC<br>
header. The resend mechanism is probably not considering what the actual<br>
content/target the  RPC has.<br>
So, in principle, the RPC could be to update a data block, or a metadata<br>
block - so it may hit just a single data file or corrupt your entire file<br>
system.<br>
However, I think the likelihood that the RPC content can go as valid RPC<br>
header is very low.<br>
<br>
<br>
Mit freundlichen Grüßen / Kind regards<br>
<br>
<br>
Dr. Uwe Falke<br>
<br>
IT Specialist<br>
High Performance Computing Services / Integrated Technology Services /<br>
Data Center Services<br>
-------------------------------------------------------------------------------------------------------------------------------------------<br>
IBM Deutschland<br>
Rathausstr. 7<br>
09111 Chemnitz<br>
Phone: <a href="tel:%2B49%20371%206978%202165">+49 371 6978 2165</a><br>
Mobile: <a href="tel:%2B49%20175%20575%202877">+49 175 575 2877</a><br>
E-Mail: <a href="mailto:uwefalke@de.ibm.com">uwefalke@de.ibm.com</a><br>
-------------------------------------------------------------------------------------------------------------------------------------------<br>
IBM Deutschland Business & Technology Services GmbH / Geschäftsführung:<br>
Thomas Wolter, Sven Schooß<br>
Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart,<br>
HRB 17122<br>
<br>
<br>
<br>
<br>
From:   Ben De Luca <<a href="mailto:bdeluca@gmail.com">bdeluca@gmail.com</a>><br>
To:     gpfsug main discussion list <<a href="mailto:gpfsug-discuss@spectrumscale.org">gpfsug-discuss@spectrumscale.org</a>><br>
Cc:     <a href="mailto:gpfsug-discuss-bounces@spectrumscale.org">gpfsug-discuss-bounces@spectrumscale.org</a><br>
Date:   10/10/2017 08:52 PM<br>
Subject:        Re: [gpfsug-discuss] FW: [EXTERNAL] FLASH: IBM Spectrum<br>
Scale (GPFS) V4.1 and 4.2 levels: network reconnect function may result in<br>
file system corruption or undetected file data corruption (2017.10.09)<br>
Sent by:        <a href="mailto:gpfsug-discuss-bounces@spectrumscale.org">gpfsug-discuss-bounces@spectrumscale.org</a><br>
<br>
<br>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">does this corrupt the entire filesystem or just the open files that are<br>
being written too?<br>
<br>
One is horrific and the other is just mildly bad.<br>
<br>
On 10 October 2017 at 17:09, IBM Spectrum Scale <<a href="mailto:scale@us.ibm.com">scale@us.ibm.com</a>> wrote:<br>
Bob,<br>
<br>
The problem may occur when the TCP connection is broken between two nodes.<br>
While in the vast majority of the cases when data stops flowing through<br>
the connection, the result is one of the nodes getting expelled, there are<br>
cases where the TCP connection simply breaks -- that is relatively rare<br>
but happens on occasion. There is logic in the mmfsd daemon to detect the<br>
disconnection and attempt to reconnect to the destination in question. If<br>
the reconnect is successful then steps are taken to recover the state kept<br>
by the daemons, and that includes resending some RPCs that were in flight<br>
when the disconnection took place.<br>
<br>
As the flash describes, a problem in the logic to resend some RPCs was<br>
causing one of the RPC headers to be omitted, resulting in the RPC data to<br>
be interpreted as the (missing) header. Normally the result is an assert<br>
on the receiving end, like the "logAssertFailed: !"Request and queue size<br>
mismatch"  assert described in the flash. However, it's at least<br>
conceivable (though expected to very rare) that the content of the RPC<br>
data could be interpreted as a valid RPC header. In the case of an RPC<br>
which involves data transfer between an NSD client and NSD server, that<br>
might result in incorrect data being written to some NSD device.<br>
<br>
Disconnect/reconnect scenarios appear to be uncommon. An entry like<br>
<br>
[N] Reconnected to xxx.xxx.xxx.xxx nodename <c0n0><br>
<br>
in mmfs.log would be an indication that a reconnect has occurred. By<br>
itself, the reconnect will not imply that data or the file system was<br>
corrupted, since that will depend on what RPCs were pending when the<br>
connection happened. In the case the assert above is hit, no corruption is<br>
expected, since the daemon will go down before incorrect data gets<br>
written.<br>
<br>
Reconnects involving an NSD server are those which present the highest<br>
risk, given that NSD-related RPCs are used to write data into NSDs<br>
<br>
Even on clusters that have not been subjected to disconnects/reconnects<br>
before, such events might still happen in the future in case of network<br>
glitches. It's then recommended that an efix for the problem be applied in<br>
a timely fashion.<br>
<br>
<br>
Reference: <a href="http://www-01.ibm.com/support/docview.wss?uid=ssg1S1010668" target="_blank">
http://www-01.ibm.com/support/docview.wss?uid=ssg1S1010668</a><br>
<br>
<br>
<br>
Regards, The Spectrum Scale (GPFS) team<br>
<br>
------------------------------------------------------------------------------------------------------------------<br>
If you feel that your question can benefit other users of  Spectrum Scale<br>
(GPFS), then please post it to the public IBM developerWroks Forum at<br>
<a href="https://www.ibm.com/developerworks/community/forums/html/forum?id=11111111-0000-0000-0000-000000000479" target="_blank">https://www.ibm.com/developerworks/community/forums/html/forum?id=11111111-0000-0000-0000-000000000479</a><br>
.<br>
<br>
If your query concerns a potential software error in Spectrum Scale (GPFS)<br>
and you have an IBM software maintenance contract please contact<br>
 <a href="tel:1-800-237-5511">1-800-237-5511</a> in the United States or your local IBM Service Center in<br>
other countries.<br>
<br>
The forum is informally monitored as time permits and should not be used<br>
for priority messages to the Spectrum Scale (GPFS) team.<br>
<br>
<br>
<br>
From:        "Oesterlin, Robert" <<a href="mailto:Robert.Oesterlin@nuance.com">Robert.Oesterlin@nuance.com</a>><br>
To:        gpfsug main discussion list <<a href="mailto:gpfsug-discuss@spectrumscale.org">gpfsug-discuss@spectrumscale.org</a>><br>
Date:        10/09/2017 10:38 AM<br>
Subject:        [gpfsug-discuss] FW: [EXTERNAL] FLASH: IBM Spectrum Scale<br>
(GPFS) V4.1 and 4.2 levels: network reconnect function may result in file<br>
system corruption or undetected file data corruption (2017.10.09)<br>
Sent by:        <a href="mailto:gpfsug-discuss-bounces@spectrumscale.org">gpfsug-discuss-bounces@spectrumscale.org</a><br>
<br>
<br>
<br>
<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">Can anyone from the Scale team comment?<br>
<br>
Anytime I see ?may result in file system corruption or undetected file<br>
data corruption? it gets my attention.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
Bob Oesterlin<br>
Sr Principal Storage Engineer, Nuance<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Storage<br>
IBM My Notifications<br>
Check out the IBM Electronic Support<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
IBM Spectrum Scale<br>
<br>
<br>
<br>
: IBM Spectrum Scale (GPFS) V4.1 and 4.2 levels: network reconnect<br>
function may result in file system corruption or undetected file data<br>
corruption<br>
<br>
<br>
<br>
IBM has identified a problem with IBM Spectrum Scale (GPFS) V4.1 and V4.2<br>
levels, in which resending an NSD RPC after a network reconnect function<br>
may result in file system corruption or undetected file data corruption.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
 _______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" target="_blank">spectrumscale.org</a><br>
<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=IbxtjdkPAM2Sbon4Lbbi4w&m=xzMAvLVkhyTD1vOuTRa4PJfiWgFQ6VHBQgr1Gj9LPDw&s=-AQv2Qlt2IRW2q9kNgnj331p8D631Zp0fHnxOuVR0pA&e=" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=IbxtjdkPAM2Sbon4Lbbi4w&m=xzMAvLVkhyTD1vOuTRa4PJfiWgFQ6VHBQgr1Gj9LPDw&s=-AQv2Qlt2IRW2q9kNgnj331p8D631Zp0fHnxOuVR0pA&e=</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br>
<br>
_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>