[lustre-discuss] 2.10 <-> 2.12 interoperability?

Thomas Roth t.roth at gsi.de
Mon May 6 06:22:24 PDT 2019


Ah yes, of course, thanks for the advise.

Come to think of it, we never did such an upgrade of the servers before (and this was just a test
system). Could have worked, though, sometimes it's just one switch ;-)

Regards,
Thomas

On 03/05/2019 22.35, Hans Henrik Happe wrote:
> On 03/05/2019 22.41, Andreas Dilger wrote:
>> On May 3, 2019, at 14:33, Patrick Farrell <pfarrell at whamcloud.com> wrote:
>>>
>>> Thomas,
>>>
>>> As a general rule, Lustre only supports mixing versions on servers for rolling upgrades.
>>>
>>> - Patrick
>>
>> And only then between maintenance versions of the same release (e.g. 2.10.6
>> and 2.10.7).  If you are upgrading, say, 2.7.21 to 2.10.6 then you would need
>> to fail over half of the targets, upgrade half of the servers, fail back (at
>> which point all targets would be running on the same new version), upgrade the
>> other half of the servers, and then restore normal operation.
>>
>> There is also a backport of the LU-11507 patch for 2.10 that could be used
>> instead of upgrading just one server to 2.12.
>>
>> Cheers, Andreas
> 
> I think the documentation is quite clear:
> 
> http://doc.lustre.org/lustre_manual.xhtml#upgradinglustre
> 
> An upgrade path for major releases on the servers would be nice, though.
> Wonder if this could be done with a mode where clients flush all they
> got and are put into a blocking mode. I guess the hard part would be to
> re-negotiate all the state after the upgrade, which is hard enough for
> regular replays.
> 
> Cheers,
> Hans Henrik
> 
>>> On Wednesday, April 24, 2019 3:54:09 AM, Thomas Roth <t.roth at gsi.de> wrote:
>>>>  
>>>> Hi all,
>>>>
>>>> OS=CentOS 7.5
>>>> Lustre 2.10.6
>>>>
>>>> One of the OSS (one OST only) was upgraded to zfs 0.7.13, and LU-11507 forced an upgrade of Lustre to 2.12
>>>>
>>>> Mounts, reconnects, recovers, but then is unusable, and the MDS reports:
>>>>
>>>> Lustre: 13650:0:(mdt_handler.c:5350:mdt_connect_internal()) test-MDT0000: client
>>>> test-MDT0000-lwp-OST0002_UUID does not support ibits lock, either very old or an invalid client: flags
>>>> 0x2041401043000020
>>>>
>>>>
>>>> So far I have not found any hints that these versions would not cooperate, or that I should have set a
>>>> certain parameter.
>>>> LU-10175 indicates that the ibits have some connection to data-on-mdt which we don't use.
>>>>
>>>> Any suggestions?
>>>>
>>>>
>>>> Regards,
>>>> Thomas
>> --
>> Andreas Dilger
>> Principal Lustre Architect
>> Whamcloud
>>
>> _______________________________________________
>> lustre-discuss mailing list
>> lustre-discuss at lists.lustre.org
>> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
>>
> _______________________________________________
> lustre-discuss mailing list
> lustre-discuss at lists.lustre.org
> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org
> 

-- 
--------------------------------------------------------------------
Thomas Roth
Department: Informationstechnologie
Location: SB3 2.291
Phone: +49-6159-71 1453  Fax: +49-6159-71 2986


GSI Helmholtzzentrum für Schwerionenforschung GmbH
Planckstraße 1, 64291 Darmstadt, Germany, www.gsi.de

Commercial Register / Handelsregister: Amtsgericht Darmstadt, HRB 1528
Managing Directors / Geschäftsführung:
Professor Dr. Paolo Giubellino, Ursula Weyrich, Jörg Blaurock
Chairman of the Supervisory Board / Vorsitzender des GSI-Aufsichtsrats:
State Secretary / Staatssekretär Dr. Georg Schütte


More information about the lustre-discuss mailing list