== sanity-lfsck test 23b: LFSCK can repair dangling name entry (2) == 05:43:26 (1441691006)
#####
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
Trigger namespace LFSCK to find out dangling name entry
Started LFSCK on the device lustre-MDT0000: scrub namespace
sanity-lfsck test_23b: @@@@@@ FAIL: (9) Fail to repair dangling name entry: 0
Trace dump:
= /usr/lib64/lustre/tests/test-framework.sh:4748:error_noexit()
= /usr/lib64/lustre/tests/test-framework.sh:4779:error()
= /usr/lib64/lustre/tests/sanity-lfsck.sh:3058:test_23b()
= /usr/lib64/lustre/tests/test-framework.sh:5026:run_one()
= /usr/lib64/lustre/tests/test-framework.sh:5063:run_one_logged()
= /usr/lib64/lustre/tests/test-framework.sh:4880:run_test()
= /usr/lib64/lustre/tests/sanity-lfsck.sh:3069:main()
Dumping lctl log to /tmp/test_logs/1441690965/sanity-lfsck.test_23b.*.1441691880.log
23b__8.lctl.tgz