<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Thanks Eric!</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I have a few follow up questions for you--</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">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 id="AppleMailSignature"><br></div><div id="AppleMailSignature">Would you mind sharing any log messages related to the errors you saw when you ran the mmchconfig?</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Thanks!<br><br>Sent from my iPhone</div><div><br>On Dec 10, 2016, at 12:31 AM, Eric Horst <<a href="mailto:erich@uw.edu">erich@uw.edu</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 5, 2016 at 1:31 PM, Aaron Knister <span dir="ltr"><<a href="mailto:aaron.s.knister@nasa.gov" target="_blank">aaron.s.knister@nasa.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2n9" class="a3s aXjCH m158d0e77058252e5">Also, if anyone has done a rolling 3.5 to 4.1 upgrade and has any anecdotes they'd like to share, I would like to hear them.<br></div></blockquote></div><br>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><blockquote type="cite"><div><span>_______________________________________________</span><br><span>gpfsug-discuss mailing list</span><br><span>gpfsug-discuss at <a href="http://spectrumscale.org">spectrumscale.org</a></span><br><span><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></span><br></div></blockquote></body></html>