Lustre discuss - Sep 2010 - 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

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.
> 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.

Cheers,
Johann

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
>

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

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
>