Could somebody (Andreas maybe :) give a definitive answer on this... > > Having said that, I believe 1.6.0 and 1.6.3 is actually something that > > will work, but I'm not 100% certain of this, so I'll allow others to > > correct me.
... as I would like to do just this, go from 1.6.0.1 to 1.6.3 and would rather not have to go through the intermediate versions if I don't have to. Thanks in advance. Ron Jerome National Research Council Canada > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:lustre-discuss- > [EMAIL PROTECTED] On Behalf Of Jody McIntyre > Sent: October 15, 2007 11:58 PM > To: Jeff Blasius > Cc: [email protected] > Subject: Re: [Lustre-discuss] lustre interoperability > > Hi Jeff, > > On Sun, Oct 14, 2007 at 11:31:45PM -0400, Jeff Blasius wrote: > > > Thank you for this information. Can or someone else comment on what > it > > means to upgrade? I assume it's not enough to simply build the > > software or update via rpm. After updating, you should go through the > > process of having all of the OSS's join the MGS/MDS and verify a > > successful client connection? > > This part is in the manual :) See: > http://manual.lustre.org/manual/LustreManual16_HTML/DynamicHTML-13- > 1.html > > > Just for my curiosity, is there a standard process the server > > components undergo during the upgrade? > > I don't understand what you mean here. Can you explain your question? > > Cheers, > Jody > > > Thank You, > > jeff > > > > On 10/12/07, Jody McIntyre <[EMAIL PROTECTED]> wrote: > > > Hi Jeff, > > > > > > On Fri, Oct 12, 2007 at 12:01:04PM -0400, Jeff Blasius wrote: > > > > > > > I've seriously trekked through the lustre documentation and > haven't > > > > found an answer regarding this. Is there an official policy > regarding > > > > interoperability among different versions of various lustre > > > > components? > > > > > > By coincidence, I just sent information about this to our > documentation > > > team. It should eventually reach the manual. Here it is: > > > > > > --- > > > Our supported upgrades are from one minor version to another, for > > > example 1.4.10 to 1.4.11 or 1.6.2 to 1.6.3, and also from the > latest > > > 1.4.x version to the latest 1.6.x version, so 1.4.11 to 1.6.3 is > > > supported. > > > > > > We also support downgrades within the same ranges. For example, if > you > > > upgrade from 1.6.2 to 1.6.3, you can also downgrade to 1.6.2 (but a > > > fresh install of 1.6.3 is _not_ guaranteed to be downgradeable.) > > > > > > Note that other combinations will work and we support them in > specific > > > cases when requested by customers, but the ranges above will always > > > work. > > > --- > > > > > > > For example (and I'm sure other groups are in the same boat > here), > > > > it's relatively painless to perform a rolling upgrade to the > lustre > > > > clients, but upgrading the OSS or MDS takes more convincing. Is > it OK > > > > for me to run a patched but 1.6.0 based OSS with a 1.6.3 client? > In > > > > this case all of the lustre components (kernel, lustre, ldiskfs) > are > > > > the same version for each host. Similarly, is it OK to run a > lustre > > > > kernel version out of sync with the userland tools? For example a > > > > 1.6.0 kernel with a 1.6.3 lustre build on the same host? > > > > > > Not necessarily. You should do a rolling upgrade to 1.6.1, then > 1.6.2, > > > then 1.6.3. Upgrading will be easier if you stay more current - > 1.6.0 > > > is fairly old at this point. > > > > > > Having said that, I believe 1.6.0 and 1.6.3 is actually something > that > > > will work, but I'm not 100% certain of this, so I'll allow others > to > > > correct me. > > > > > > Cheers, > > > Jody > > > > > > > I understand that many of these combinations do in fact work, I'm > more > > > > interested if they're likely to lead to data corruption or client > > > > evictions. I'm not sure how often incompatibilities arise, but if > it's > > > > relatively rare, it would be useful if that was announced on the > > > > change log. Of course if there's a serious "Do at your own risk" > > > > policy that would also be useful to know. > > > > > > > > Thank You, > > > > jeff > > > > > > > > -- > > > > Jeff Blasius / [EMAIL PROTECTED] > > > > Phone: (203)432-9940 51 Prospect Rm. 011 > > > > High Performance Computing (HPC) > > > > Linux Systems Design & Support (LSDS) > > > > Yale University Information Technology Services (ITS) > > > > > > > > _______________________________________________ > > > > Lustre-discuss mailing list > > > > [email protected] > > > > https://mail.clusterfs.com/mailman/listinfo/lustre-discuss > > > > > > > > > > -- > > > > > > > > > -- > > Jeff Blasius / [EMAIL PROTECTED] > > Phone: (203)432-9940 51 Prospect Rm. 011 > > High Performance Computing (HPC) > > UNIX Systems Administrator, Linux Systems Design & Support (LSDS) > > Yale University Information Technology Services (ITS) > > > > -- > > _______________________________________________ > Lustre-discuss mailing list > [email protected] > https://mail.clusterfs.com/mailman/listinfo/lustre-discuss _______________________________________________ Lustre-discuss mailing list [email protected] https://mail.clusterfs.com/mailman/listinfo/lustre-discuss
