[LU-5906] Interop 2.6.0<->master ost-pools test_1d: FAIL: pool_new failed lustre.testpool12345678 Created: 11/Nov/14 Updated: 02/Sep/15 Resolved: 26/May/15 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.7.0, Lustre 2.5.3, Lustre 2.8.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor |
| Reporter: | Maloo | Assignee: | WC Triage |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Environment: |
server: 2.6.0 |
||
| Issue Links: |
|
||||||||
| Severity: | 3 | ||||||||
| Rank (Obsolete): | 16496 | ||||||||
| Description |
|
This issue was created by maloo for sarah <sarah@whamcloud.com> 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 |
| Comments |
| Comment by Andreas Dilger [ 12/Nov/14 ] |
|
It looks like this failure is caused by the landing of the following patch on master: commit 2305c36139a7deaf25a0dc737d412eed42ca54e9
Author: Li Xi <lixi@ddn.com>
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 <lixi@ddn.com>
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. |
| Comment by Andreas Dilger [ 26/May/15 ] |
|
This should be fixed in the b2_5 branch via |