[LU-8845] sanityn test_80b: test failed to respond and timed out

• Status: Resolved
• Project: Lustre
• Type: Bug
• Priority: Minor
• Reporter: Maloo
• Assignee: WC Triage
• Resolution: Cannot Reproduce
• Severity: 3

Description

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

Please provide additional information about the failure here.

This issue relates to the following test suite run: https://testing.hpdd.intel.com/test_sets/f72d26ba-ac24-11e6-971d-5254006e85c2.

== sanityn test 80b: Accessing directory during migration ============================================ 10:50:49 (1479293449)
start migration thread 4442
accessing the migrating directory for 5 minutes...
...0 seconds
...10 seconds

Issue Links

• is related to: LU-8942 bad test in sanityn test_80b

Comments

[Jian Yu]

One more failure instance on master branch:
https://testing.hpdd.intel.com/test_sets/11eed540-ac8c-11e6-95d8-5254006e85c2

[Andreas Dilger]

I noticed in the client console log from sanityn test_80b is being flooded with messages:
https://testing.hpdd.intel.com/test_sets/c377fbac-b96a-11e7-8afb-52540065bddc
https://testing.hpdd.intel.com/test_logs/c408c29a-b96a-11e7-8afb-52540065bddc/show_text

lov_object.c:176:lov_init_sub()) header@ffff88006afe6348[0x0, 2, [0x340000400:0x362:0x0] hash] {
lov_object.c:176:lov_init_sub()) ....lovsub@ffff88006afe63a8[0]
lov_object.c:176:lov_init_sub()) ....osc@ffff880048726618id: 0x340000400:866 idx: 1 gen: 0 kms_valid: 1 kms 0 rc: 0 force_sync: 0 min_xid: 0 size: 0 mtime: 1508897801 atime: 1508897801 ctime: 1508897801 blocks: 0
lov_object.c:176:lov_init_sub()) } header@ffff88006afe6348
lov_object.c:176:lov_init_sub()) stripe 0 is already owned.
lov_object.c:177:lov_init_sub()) header@ffff88004e694f20[0x0, 1, [0x2800013a3:0x138c:0x0] hash] {
lov_object.c:177:lov_init_sub()) ....vvp@ffff88004e694f80(0 0) inode: ffff88004b663b10 180144069433889676/41943059 100644 1 1 ffff88004e694f80 [0x2800013a3:0x138c:0x0]
lov_object.c:177:lov_init_sub()) ....lov@ffff88006b3d1140entries: 1, valid, lsm{ffff88006ad2fc80 0x0BD10BD0 1 0}:
lov_object.c:177:lov_init_sub()) [ 0x0 , 0xffffffffffffffff ): { 0x0BD10BD0, 0, 0, 0x10, 1, 1048576 }
lov_object.c:177:lov_init_sub()) header@ffff88006afe6348[0x0, 2, [0x340000400:0x362:0x0] hash] {
lov_object.c:177:lov_init_sub()) ....lovsub@ffff88006afe63a8[0]
lov_object.c:177:lov_init_sub()) ....osc@ffff880048726618id: 0x340000400:866 idx: 1 gen: 0 kms_valid: 1 kms 0 rc: 0 force_sync: 0 min_xid: 0 size: 0 mtime: 1508897801 atime: 1508897801 ctime: 1508897801 blocks: 0
lov_object.c:177:lov_init_sub()) } header@ffff88006afe6348
lov_object.c:177:lov_init_sub()) } header@ffff88004e694f20
lov_object.c:177:lov_init_sub()) owned.
lov_object.c:178:lov_init_sub()) header@ffff88004e694a50[0x0, 1, [0x2c00013a0:0x15:0x0]]
lov_object.c:178:lov_init_sub()) try to own.
lcommon_cl.c:180:cl_file_inode_init()) Failure to initialize cl object [0x2c00013a0:0x15:0x0]: -5
llite_lib.c:2326:ll_prep_inode()) new_inode -fatal: rc -5

If this is something that can happen during normal operation, then it probably shouldn't be dumped to the console.