Ms. Megan Larko
2010-Sep-27 16:31 UTC
[Lustre-discuss] upgrade to 1.8.4 and test fallback to 1.6.7.2
Greetings! I performed an upgrade of our Lustre file system and corresponding SuSE kernel. The Lustre upgrade went well. After the upgrade from 1.6.7.2 to 1.8.4 I was able to mount my Lustre volumes. The data was fine. The quotas started on mount via the lustre params on the MDT and OSTs. I attempted to add a new lustre tuning parameter to my system (I wanted to add the *t.group_upcall=NONE.) While the Lustre 1.8.4 read the 1.6.7.2 tuning parameters without issue and I could add to the parameters under 1.8.4 without issue, if I tried to change a parameter requiring that I use the --writeconf option, I learned I had to change all the parameters from the 1.6.7.2 syntax to the 1.8.4 syntax. (EXAMPLE: "failover.node" string became "failnode") Okay. This I can do, BUT... If I have to revert to 1.6.7.2 (due to a security flaw in the linux kernel or something...) am I correct in assuming that the lustre 1.8.4 parameter strings would not be understood by the 1.6.7.2 lustre system (can''t have s/w reading into the future, right? Smile)? If that is the case, then I should not change my lustre 1.6.7.2 parameters into the newer 1.8.4 strings until I am certain I won''t have to revert back, or be prepared to do a full --writeconf of all *Ts to use the older 1.6.7.2 strings after going back to the previous kernel containing the lustre 1.6.7.2 files. Am I correct on this understanding? Thanks, Megan Larko SGI Federal
Johann Lombardi
2010-Sep-27 17:12 UTC
[Lustre-discuss] upgrade to 1.8.4 and test fallback to 1.6.7.2
On Mon, Sep 27, 2010 at 12:31:53PM -0400, Ms. Megan Larko wrote:> I attempted to add a new lustre tuning parameter to my system (I > wanted to add the *t.group_upcall=NONE.) While the Lustre 1.8.4 readPlease note that *t.group_upcall=NONE is already supported in 1.6.> the 1.6.7.2 tuning parameters without issue and I could add to the > parameters under 1.8.4 without issue, if I tried to change a parameter > requiring that I use the --writeconf option, I learned I had to change > all the parameters from the 1.6.7.2 syntax to the 1.8.4 syntax. > (EXAMPLE: "failover.node" string became "failnode") Okay. This I > can do, BUT... > > If I have to revert to 1.6.7.2 (due to a security flaw in the linux > kernel or something...) am I correct in assuming that the lustre 1.8.4 > parameter strings would not be understood by the 1.6.7.2 lustre system > (can''t have s/w reading into the future, right? Smile)? If that isTo be clear, lustre 1.8 and 1.6 use the same string format. 1.8 just supports some additional parameters introduced for to the new features (e.g. OST pools). Unknown params are supposed to be ignored when downgrading. While it works fine with most of the new params (like OST pools), there is unfortunately a bug (i.e. it does not work with at_max), see bug 20449. Cheers, Johann
Ms. Megan Larko
2010-Sep-27 17:50 UTC
[Lustre-discuss] upgrade to 1.8.4 and test fallback to 1.6.7.2
Greetings Johann, Thank you for your response. On Mon, Sep 27, 2010 at 1:12 PM, Johann Lombardi <johann.lombardi at oracle.com> wrote:> On Mon, Sep 27, 2010 at 12:31:53PM -0400, Ms. Megan Larko wrote: >> I attempted to add a new lustre tuning parameter to my system (I >> wanted to add the *t.group_upcall=NONE.) ? While the Lustre 1.8.4 read > > Please note that *t.group_upcall=NONE is already supported in 1.6.Yes. I know that *t.group_upcall=NONE is supported in 1.6. Our site at SGI did not have its 1.6.7.2 Lustre configured that way. The SGI site was using the default and I wanted to change it after upgrading to 1.8.4. I apologize if I was not clear.> >> the 1.6.7.2 tuning parameters without issue and I could add to the >> parameters under 1.8.4 without issue, if I tried to change a parameter >> requiring that I use the --writeconf option, I learned I had to change >> all the parameters from the 1.6.7.2 syntax to the 1.8.4 syntax. >> (EXAMPLE: ? "failover.node" string became "failnode") ? ?Okay. ?This I >> can do, ? BUT... >> >> If I have to revert to 1.6.7.2 (due to a security flaw in the linux >> kernel or something...) am I correct in assuming that the lustre 1.8.4 >> parameter strings would not be understood by the 1.6.7.2 lustre system >> (can''t have s/w reading into the future, right? ? Smile)? ? If that is > > To be clear, lustre 1.8 and 1.6 use the same string format. 1.8 just supports > some additional parameters introduced for to the new features (e.g. OST pools). > Unknown params are supposed to be ignored when downgrading. While it works > fine with most of the new params (like OST pools), there is unfortunately a > bug (i.e. it does not work with at_max), see bug 20449.Okay....I was getting errors when I attempted to use --erase-params and --writeconf in 1.8.4 stating that my 1.6.7.2 parameters would have to be updated (again, my "failover.node" string becomes "failnode" string). Just my personal experience so far... Thank you, MLarko> > Cheers, > Johann >
Johann Lombardi
2010-Sep-27 21:10 UTC
[Lustre-discuss] upgrade to 1.8.4 and test fallback to 1.6.7.2
Hi Megan, On Mon, Sep 27, 2010 at 01:50:38PM -0400, Ms. Megan Larko wrote:> Okay....I was getting errors when I attempted to use --erase-params > and --writeconf in 1.8.4 stating that my 1.6.7.2 parameters would have > to be updated (again, my "failover.node" string becomes "failnode" > string). Just my personal experience so far...--failnode is actually very similar to --param="failover.node=". In both cases, the same parameter (i.e. PARAM_FAILNODE="failover.node=") is stored in the configuration logs. The only difference is that --failnode enables MMP automatically, that''s why we recommend to use it. To sum up, there should not be any compatibility issue (BTW, --failnode is also available in 1.6, AFAIK). Cheers, Johann
Ms. Megan Larko
2010-Sep-29 16:58 UTC
[Lustre-discuss] upgrade to 1.8.4 and test fallback to 1.6.7.2
Wow. I did not know that difference. I like what I have read about MMP. Thank you. MLarko SGI Federal On Mon, Sep 27, 2010 at 5:10 PM, Johann Lombardi <johann.lombardi at oracle.com> wrote:> Hi Megan, > > On Mon, Sep 27, 2010 at 01:50:38PM -0400, Ms. Megan Larko wrote: >> Okay....I was getting errors when I attempted to use --erase-params >> and --writeconf in 1.8.4 stating that my 1.6.7.2 parameters would have >> to be updated (again, my "failover.node" string becomes "failnode" >> string). ?Just my personal experience so far... > > --failnode is actually very similar to --param="failover.node=". > In both cases, the same parameter (i.e. PARAM_FAILNODE="failover.node=") is > stored in the configuration logs. The only difference is that --failnode > enables MMP automatically, that''s why we recommend to use it. > To sum up, there should not be any compatibility issue (BTW, --failnode is > also available in 1.6, AFAIK). > > Cheers, > Johann >