[LU-7216] interop: Changeling <-> master sanity-lfsck_23b test failed Lustre: DEBUG MARKER: sanity-lfsck test_23b: @@@@@@ FAIL: (6) ls should fail.

Thu, 27 Feb 2020 23:40:00 +0000

== sanity-lfsck test 23b: LFSCK can repair dangling name entry (2) == 02:25:47 (1442715947)
#####
The objectA has multiple hard links, one of them corresponding
to the name entry_B. But there is something wrong for the name
entry_B and cause entry_B to references non-exist object_C.
In the first-stage scanning, the LFSCK will think the entry_B
as dangling, and re-create the lost object_C. When the LFSCK
comes to the second-stage scanning, it will find that the
former re-creating object_C is not proper, and will try to
replace the object_C with the real object_A.
#####
Inject failure stub on MDT0 to simulate dangling name entry
fail_loc=0x1621
fail_loc=0
'ls' should fail because of dangling name entry
 sanity-lfsck test_23b: @@@@@@ FAIL: (6) ls should fail. 
  Trace dump:
  = /usr/lib64/lustre/tests/test-framework.sh:4784:error_noexit()
  = /usr/lib64/lustre/tests/test-framework.sh:4815:error()
  = /usr/lib64/lustre/tests/sanity-lfsck.sh:3042:test_23b()
  = /usr/lib64/lustre/tests/test-framework.sh:5062:run_one()
  = /usr/lib64/lustre/tests/test-framework.sh:5099:run_one_logged()
  = /usr/lib64/lustre/tests/test-framework.sh:4916:run_test()
  = /usr/lib64/lustre/tests/sanity-lfsck.sh:3069:main()
Dumping lctl log to /tmp/test_logs/1442715921/sanity-lfsck.test_23b.*.1442715947.log
FAIL 23b (1s)

Whamcloud Community JIRA

[LU-7216] interop: Changeling <-> master sanity-lfsck_23b test failed Lustre: DEBUG MARKER: sanity-lfsck test_23b: @@@@@@ FAIL: (6) ls should fail.