[LU-5906] Interop 2.6.0<->master ost-pools test_1d: FAIL: pool_new failed lustre.testpool12345678

• Type: Bug
• Resolution: Duplicate
• Priority: Minor
• Affects Version/s: Lustre 2.7.0, Lustre 2.5.3, Lustre 2.8.0
• Environment: server: 2.6.0; client: lustre-master build #2733
• Severity: 3
• Assignee: WC Triage
• Reporter: Maloo

Description

This issue was created by maloo for sarah <[e-mail]>

This issue relates to the following test suite run: https://testing.hpdd.intel.com/test_sets/8190b56c-68ff-11e4-9444-5254006e85c2.

The sub-test test_1d failed with the following error:

pool_new failed lustre.testpool12345678

CMD: onyx-44vm2.onyx.hpdd.intel.com lctl get_param -n lov.lustre-*.pools.testpool12345678         2>/dev/null || echo foo
Update not seen after 90s: wanted '' got 'foo'
 ost-pools test_1d: @@@@@@ FAIL: pool_new failed lustre.testpool12345678 

Info required for matching: ost-pools 1d

Issue Links

• is duplicated by: LU-6463 Interop 2.5.3<->master ost-pools test_1c: Pool creation of testpool12345678 failed

Comments

[Andreas Dilger]

This should be fixed in the b2_5 branch via LU-6463, since we no longer test interop with 2.6.0.

[Andreas Dilger]

It looks like this failure is caused by the landing of the following patch on master:

commit 2305c36139a7deaf25a0dc737d412eed42ca54e9
Author: Li Xi <[e-mail]>
Date:   Fri Oct 3 07:43:02 2014 +0800

    LU-5054 llite: enforce pool name length limit
    
    The pool related codes have some inconsistency about the length
    of pool name. Creating and setting a pool name of lenght 16
    to a directory will succeed. However, creating a file under
    that directory will fail.
    
    This patch disables any pool name which is longer or equal to
    16. And it changes LOV_MAXPOOLNAME from 16 to 15 which might
    cause some invalid LLOG records of OST pools with 16 byte names.
    It is not a problem since invalid LLOG records are just ignored.
    And OST pools with 16 byte names won't work well anyway on the
    old versions. There will be problem of inconsistency if part of
    the servers have this patch and part of the servers don't. But
    it would be safe to assume that this is not a normal
    configuration.
    
    Signed-off-by: Li Xi <[e-mail]>
    Change-Id: I3672fb5414662120c3e6b8641002a6b76994cc77
    Reviewed-on: http://review.whamcloud.com/10306

I don't think this is something we will fix for b2_6, but it probably should be backported to b2_5 to avoid test failures there.