<div dir="ltr">Sven,<div><br></div><div>For us, at least, at this point in time, we have to create new filesystem with version flag. The reason is we can't take downtime to upgrade all of our 500+ compute nodes that will cross-cluster mount this new storage. We can take downtime in June and get all of the nodes up to 4.2 gpfs version but we have users today that need to start using the filesystem. </div><div><br></div><div>So at this point in time, we either have ESS built with 4.1 version and cross mount its filesystem (also built with --version flag I assume) to our 3.5 compute cluster, or...we proceed with 4.2 ESS and build filesystems with --version flag and then in June when we get all of our clients upgrade we run =latest gpfs command and then mmchfs -V to get filesystem back up to 4.2 features. </div><div><br></div><div>It's unfortunate that we are in this bind with the downtime of the compute cluster. If we were allowed to upgrade our compute nodes before June, we could proceed with 4.2 build without having to worry about filesystem versions. </div><div><br></div><div>Thanks for your reply.</div><div><br></div><div>Damir</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 16, 2016 at 12:18 PM Sven Oehme <<a href="mailto:oehmes@gmail.com">oehmes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">while this is all correct people should think twice about doing this.<div>if you create a filesystem with older versions, it might prevent you from using some features like data-in-inode, encryption, adding 4k disks to existing filesystem, etc even if you will eventually upgrade to the latest code. </div><div><br></div><div>for some customers its a good point in time to also migrate to larger blocksizes compared to what they run right now and migrate the data. i have seen customer systems gaining factors of performance improvements even on existing HW by creating new filesystems with larger blocksize and latest filesystem layout (that they couldn't before due to small file waste which is now partly solved by data-in-inode). while this is heavily dependent on workload and environment its at least worth thinking about. </div></div><div dir="ltr"><div><br></div><div>sven </div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 16, 2016 at 4:20 PM, Marc A Kaplan <span dir="ltr"><<a href="mailto:makaplan@us.ibm.com" target="_blank">makaplan@us.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font size="2" face="sans-serif">The key point is that you must create the
file system so that is "looks" like a 3.5 file system.  See
mmcrfs ... --version.  Tip: create or find a test filesystem back
on the 3.5 cluster and look at the version string.  mmslfs xxx -V.
 Then go to the 4.x system and try to create a file system with the
same version string....<br></font><br><br><img align="left" src="cid:_1_1119110811190EC800544F7685257F78" alt="Marc A Kaplan" style="border:0px solid"><br><br>_______________________________________________<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/listinfo/gpfsug-discuss</a><br>
<br></blockquote></div><br></div>
_______________________________________________<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/listinfo/gpfsug-discuss</a><br>
</blockquote></div>