[LU-5130] Test failure sanity test_17n: destroy remote dir error 0

• Type: Bug
• Resolution: Duplicate
• Priority: Critical
• Affects Version/s: Lustre 2.6.0
• Severity: 3
• Assignee: Di Wang (Inactive)
• Reporter: Maloo

Description

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

This issue relates to the following test suite run:
https://maloo.whamcloud.com/test_sets/f8142678-e8e5-11e3-849b-52540035b04c
https://maloo.whamcloud.com/test_sets/92c4a4ee-e4fa-11e3-a294-52540035b04c

The sub-test test_17n failed with the following error:

rm: cannot remove `/mnt/lustre/d17n.sanity/remote_dir_0': Stale file handle
destroy remote dir error 0

Info required for matching: sanity 17n

Issue Links

• is related to: LU-5420 Failure on test suite sanity test_17m: mount MDS failed, Input/output error

Comments

[Di Wang (Inactive)]

duplicate with LU-5420.

[Di Wang (Inactive)]

I checked the console log, should be related with LU-5420, i.e. stale config log caused the OST is not being setup correctly.

21:30:38:Lustre: lustre-MDT0001: Recovery over after 0:04, of 5 clients 5 recovered and 0 were evicted.
21:30:38:LustreError: 3444:0:(lod_lov.c:821:validate_lod_and_idx()) lustre-MDT0001-mdtlov: bad idx: 7 of 32
21:30:38:Lustre: DEBUG MARKER: /usr/sbin/lctl mark  sanity test_17n: @@@@@@ FAIL: destroy remote dir error 0 

[Nathaniel Clark]

Re-occurance on master:
https://testing.hpdd.intel.com/test_sets/500c0696-87e4-11e4-a70f-5254006e85c2
https://testing.hpdd.intel.com/test_sets/e01556ea-762b-11e4-8532-5254006e85c2
https://testing.hpdd.intel.com/test_sets/081395c6-6cb3-11e4-8bd3-5254006e85c2
https://testing.hpdd.intel.com/test_sets/8f143d96-6b37-11e4-b1b4-5254006e85c2

[Jodi Levi (Inactive)]

Patch landed to Master.

[Di Wang (Inactive)]

Andreas: it is a fix for remote dir unlink error, not just optimization, so probably should go into 2.6.0. The patch still have some problem according to the maloon test, I am trying to figure out now. Thanks.

[Andreas Dilger]

Di, is the http://review.whamcloud.com/10841 patch fixing a critical enough problem that it should land for 2.6.0, or is it just an optimization?

[Di Wang (Inactive)]

http://review.whamcloud.com/10841

[Di Wang (Inactive)]

This seems related with lod object initialization process, which unnecessarily load the stripping object, I will cook a patch.

[Andreas Dilger]

Di, can you take a quick look at this? Is this a regression of some kind?