Details
-
Bug
-
Resolution: Duplicate
-
Minor
-
None
-
Lustre 2.8.0
-
None
-
3
-
9223372036854775807
Description
Server 2.7.59
Client 2.7.59
Reproducible.
Configuration : quartet
== 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