<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Dec 10, 2016 at 4:35 AM, Aaron Knister <span dir="ltr"><<a href="mailto:aaron.knister@gmail.com" target="_blank">aaron.knister@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>Thanks Eric!</div><div id="gmail-m_192408442655572608AppleMailSignature"><br></div><div id="gmail-m_192408442655572608AppleMailSignature">I have a few follow up questions for you--</div><div id="gmail-m_192408442655572608AppleMailSignature"><br></div><div id="gmail-m_192408442655572608AppleMailSignature">Do you recall the exact versions of 3.5 and 4.1 your cluster went from/to? I'm curious to know what version of 4.1 you were at when you ran the mmchconfig. </div></div></blockquote><div><br></div><div>I went from 3.5.0-28 to 4.1.0-8 to 4.2.1-1.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div id="gmail-m_192408442655572608AppleMailSignature"><br></div><div id="gmail-m_192408442655572608AppleMailSignature">Would you mind sharing any log messages related to the errors you saw when you ran the mmchconfig?</div><div id="gmail-m_192408442655572608AppleMailSignature"><br></div></div></blockquote><div><br></div><div>Unfortunately I didn't save any actual logs from the update. I did the first cluster in early July so nothing remains. The only note I have is:</div><div><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:14px">"On update, after finalizing gpfs 4.1 the quota file format apparently changed and caused a mmrepquota hang/deadlock. Had to shutdown and restart the whole cluster."</span><br></div><div><br></div><div><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:14px">Sorry to not be very helpful on that front.</span></div><div><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:14px"><br></span></div><div><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:14px">-Eric</span></div><div><span style="color:rgb(51,51,51);font-family:arial,sans-serif;font-size:14px"><br></span></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="gmail-h5"><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra">I recently did a rolling upgrade from 3.5 to 4.1 to 4.2 on two different clusters. Two things:</div><div class="gmail_extra"><br></div><div class="gmail_extra">Upgrading from 3.5 to 4.1 I did node at a time and then at the end mmchconfig release=LATEST. Minutes after flipping to latest the cluster became non-responsive, with node mmfs panics and everything had to be restarted. Logs indicated it was a quota problem. In 4.1 the quota files move from externally visible files to internal hidden files. I suspect the quota file transition can't be done without a cluster restart. When I did the second cluster I upgraded all nodes and then very quickly stopped and started the entire cluster, issuing the mmchconfig in the middle. No quota panic problems on that one.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Upgrading from 4.1 to 4.2 I did node at a time and then at the end mmchconfig release=LATEST. No cluster restart. Everything seemed to work okay. Later, restarting a node I got weird fstab errors on gpfs startup and using certain commands, notably mmfind, the command would fail with something like "can't find /dev/uwfs" (our filesystem.) I restarted the whole cluster and everything began working normally. In this case 4.2 got rid of /dev/fsname. Just like in the quota case it seems that this transition can't be seamless. Doing the second cluster I upgraded all nodes and then again quickly restarted gpfs to avoid the same problem.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Other than these two quirks, I heartily thank IBM for making a very complex product with a very easy upgrade procedure. I could imagine many ways that an upgrade hop of two major versions in two weeks could go very wrong but the quality of the product and team makes my job very easy.</div><div class="gmail_extra"><br></div><div class="gmail_extra">-Eric</div><div class="gmail_extra"><br></div></div>
</div></blockquote></div></div><span class="gmail-"><blockquote type="cite"><div><span>______________________________<wbr>_________________</span><br><span>gpfsug-discuss mailing list</span><br><span>gpfsug-discuss at <a href="http://spectrumscale.org" target="_blank">spectrumscale.org</a></span><br><span><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" target="_blank">http://gpfsug.org/mailman/<wbr>listinfo/gpfsug-discuss</a></span><br></div></blockquote></span></div><br>______________________________<wbr>_________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at <a href="http://spectrumscale.org" rel="noreferrer" target="_blank">spectrumscale.org</a><br>
<a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss" rel="noreferrer" target="_blank">http://gpfsug.org/mailman/<wbr>listinfo/gpfsug-discuss</a><br>
<br></blockquote></div><br></div></div>