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 <pfarr...@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.r...@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@lists.lustre.org >> http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org >> > _______________________________________________ > lustre-discuss mailing list > lustre-discuss@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 _______________________________________________ lustre-discuss mailing list lustre-discuss@lists.lustre.org http://lists.lustre.org/listinfo.cgi/lustre-discuss-lustre.org