<html><body>
<p><font size="2" face="sans-serif">Please see question 2.10 in our faq. </font><br>
<a href="http://www.ibm.com/support/knowledgecenter/api/content/nl/en-us/STXKQY/gpfsclustersfaq.pdf"><font size="2" face="sans-serif">http://www.ibm.com/support/knowledgecenter/api/content/nl/en-us/STXKQY/gpfsclustersfaq.pdf</font></a><br>
<br>
<font size="2" face="sans-serif">We only support clusters that are running release n and release n-1 and release n+1. So 4.1 is supported to work with 3.5 and 4.2. Release 4.2 is supported to work with 4.1, but not with gpfs 3.5. It may indeed work, but it is not supported. <br>
</font><br>
<br>
<font size="2" face="sans-serif">Steve Duersch<br>
Spectrum Scale (GPFS) FVTest<br>
845-433-7902<br>
IBM Poughkeepsie, New York<br>
<br>
</font><br>
<tt><font size="2">>>Message: 1<br>
>>Date: Wed, 16 Mar 2016 18:07:59 +0000<br>
>>From: Damir Krstic <damir.krstic@gmail.com><br>
>>To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br>
>>Subject: Re: [gpfsug-discuss] cross-cluster mounting different<br>
>> versions of gpfs<br>
>>Message-ID:<br>
>> <CAKV+WqezNdrNX1KsAqZt9A5o6gQcrh560HKN1=iNV4ZoTCLTRA@mail.gmail.com><br>
>>Content-Type: text/plain; charset="utf-8"<br>
>><br>
>>Sven,<br>
>><br>
>>For us, at least, at this point in time, we have to create new filesystem<br>
>>with version flag. The reason is we can't take downtime to upgrade all of<br>
>>our 500+ compute nodes that will cross-cluster mount this new storage. We<br>
>>can take downtime in June and get all of the nodes up to 4.2 gpfs version<br>
>>but we have users today that need to start using the filesystem.<br>
>><br>
>>So at this point in time, we either have ESS built with 4.1 version and<br>
>>cross mount its filesystem (also built with --version flag I assume) to our<br>
>>3.5 compute cluster, or...we proceed with 4.2 ESS and build filesystems<br>
>>with --version flag and then in June when we get all of our clients upgrade<br>
>>we run =latest gpfs command and then mmchfs -V to get filesystem back up to<br>
>>4.2 features.<br>
>><br>
>>It's unfortunate that we are in this bind with the downtime of the compute<br>
>>cluster. If we were allowed to upgrade our compute nodes before June, we<br>
>>could proceed with 4.2 build without having to worry about filesystem<br>
>>versions.<br>
>><br>
>>Thanks for your reply.<br>
>><br>
>>Damir<br>
</font></tt><font size="2" face="sans-serif"><br>
</font><br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF5EBDFFC62378f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for gpfsug-discuss-request---03/16/2016 02:08:37 PM---Send gpfsug-discuss mailing list submissions to gp"><font size="2" color="#424282" face="sans-serif">gpfsug-discuss-request---03/16/2016 02:08:37 PM---Send gpfsug-discuss mailing list submissions to gpfsug-discuss@spectrumscale.org</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">gpfsug-discuss-request@spectrumscale.org</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">gpfsug-discuss@spectrumscale.org</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">03/16/2016 02:08 PM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">gpfsug-discuss Digest, Vol 50, Issue 47</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Sent by: </font><font size="1" face="sans-serif">gpfsug-discuss-bounces@spectrumscale.org</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><font size="2">Send gpfsug-discuss mailing list submissions to<br>
gpfsug-discuss@spectrumscale.org<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
</font></tt><tt><font size="2"><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></font></tt><tt><font size="2"><br>
or, via email, send a message with subject or body 'help' to<br>
gpfsug-discuss-request@spectrumscale.org<br>
<br>
You can reach the person managing the list at<br>
gpfsug-discuss-owner@spectrumscale.org<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of gpfsug-discuss digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: cross-cluster mounting different versions of gpfs<br>
(Damir Krstic)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 16 Mar 2016 18:07:59 +0000<br>
From: Damir Krstic <damir.krstic@gmail.com><br>
To: gpfsug main discussion list <gpfsug-discuss@spectrumscale.org><br>
Subject: Re: [gpfsug-discuss] cross-cluster mounting different<br>
versions of gpfs<br>
Message-ID:<br>
<CAKV+WqezNdrNX1KsAqZt9A5o6gQcrh560HKN1=iNV4ZoTCLTRA@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Sven,<br>
<br>
For us, at least, at this point in time, we have to create new filesystem<br>
with version flag. The reason is we can't take downtime to upgrade all of<br>
our 500+ compute nodes that will cross-cluster mount this new storage. We<br>
can take downtime in June and get all of the nodes up to 4.2 gpfs version<br>
but we have users today that need to start using the filesystem.<br>
<br>
So at this point in time, we either have ESS built with 4.1 version and<br>
cross mount its filesystem (also built with --version flag I assume) to our<br>
3.5 compute cluster, or...we proceed with 4.2 ESS and build filesystems<br>
with --version flag and then in June when we get all of our clients upgrade<br>
we run =latest gpfs command and then mmchfs -V to get filesystem back up to<br>
4.2 features.<br>
<br>
It's unfortunate that we are in this bind with the downtime of the compute<br>
cluster. If we were allowed to upgrade our compute nodes before June, we<br>
could proceed with 4.2 build without having to worry about filesystem<br>
versions.<br>
<br>
Thanks for your reply.<br>
<br>
Damir<br>
<br>
On Wed, Mar 16, 2016 at 12:18 PM Sven Oehme <oehmes@gmail.com> wrote:<br>
<br>
> while this is all correct people should think twice about doing this.<br>
> if you create a filesystem with older versions, it might prevent you from<br>
> using some features like data-in-inode, encryption, adding 4k disks to<br>
> existing filesystem, etc even if you will eventually upgrade to the latest<br>
> code.<br>
><br>
> for some customers its a good point in time to also migrate to larger<br>
> blocksizes compared to what they run right now and migrate the data. i have<br>
> seen customer systems gaining factors of performance improvements even on<br>
> existing HW by creating new filesystems with larger blocksize and latest<br>
> filesystem layout (that they couldn't before due to small file waste which<br>
> is now partly solved by data-in-inode). while this is heavily dependent on<br>
> workload and environment its at least worth thinking about.<br>
><br>
> sven<br>
><br>
><br>
><br>
> On Wed, Mar 16, 2016 at 4:20 PM, Marc A Kaplan <makaplan@us.ibm.com><br>
> wrote:<br>
><br>
>> The key point is that you must create the file system so that is "looks"<br>
>> like a 3.5 file system. See mmcrfs ... --version. Tip: create or find a<br>
>> test filesystem back on the 3.5 cluster and look at the version string.<br>
>> mmslfs xxx -V. Then go to the 4.x system and try to create a file system<br>
>> with the same version string....<br>
>><br>
>><br>
>> [image: Marc A Kaplan]<br>
>><br>
>> _______________________________________________<br>
>> gpfsug-discuss mailing list<br>
>> gpfsug-discuss at spectrumscale.org<br>
>> </font></tt><tt><font size="2"><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></font></tt><tt><font size="2"><br>
>><br>
>><br>
> _______________________________________________<br>
> gpfsug-discuss mailing list<br>
> gpfsug-discuss at spectrumscale.org<br>
> </font></tt><tt><font size="2"><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></font></tt><tt><font size="2"><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <</font></tt><tt><font size="2"><a href="http://gpfsug.org/pipermail/gpfsug-discuss/attachments/20160316/58097bbf/attachment.html">http://gpfsug.org/pipermail/gpfsug-discuss/attachments/20160316/58097bbf/attachment.html</a></font></tt><tt><font size="2">><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: not available<br>
Type: image/gif<br>
Size: 21994 bytes<br>
Desc: not available<br>
URL: <</font></tt><tt><font size="2"><a href="http://gpfsug.org/pipermail/gpfsug-discuss/attachments/20160316/58097bbf/attachment.gif">http://gpfsug.org/pipermail/gpfsug-discuss/attachments/20160316/58097bbf/attachment.gif</a></font></tt><tt><font size="2">><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
gpfsug-discuss mailing list<br>
gpfsug-discuss at spectrumscale.org<br>
</font></tt><tt><font size="2"><a href="http://gpfsug.org/mailman/listinfo/gpfsug-discuss">http://gpfsug.org/mailman/listinfo/gpfsug-discuss</a></font></tt><tt><font size="2"><br>
<br>
<br>
End of gpfsug-discuss Digest, Vol 50, Issue 47<br>
**********************************************<br>
<br>
</font></tt><br>
<br>
</body></html>