[LU-5184] sanity-lfsck test 18d: file size never checked

• Type: Bug
• Resolution: Not a Bug
• Priority: Minor
• Affects Version/s: Lustre 2.6.0
• Labels: lfsck
• Severity: 3
• Assignee: WC Triage
• Reporter: James Nunez (Inactive)

Description

After creating a dangling reference, sanity-lfsck test 18d checks a file's size to make sure that there is an inconsistency. From test_18d:

	echo "The file size should be incorrect since dangling referenced"
	local cur_size=$(ls -il $DIR/$tdir/a1/f2 | awk '{ print $6 }')
	[ "$cur_size" != "$saved_size" ] ||
		error "(1) Expect incorrect file2 size"

but, when there is a dangling reference, ls does not return the file size. From the output of test_18d:

The file size should be incorrect since dangling referenced
ls: cannot access /lustre/scratch/d18d.sanity-lfsck/a1/f2: Cannot allocate memory

Thus, the file size is never checked and this code does not do what is intended. This check needs to be rethought; it should probably be taken out or a different failure other than dangling reference needs to be injected here.

Issue Links

• is related to: LU-4970 Test failure sanity-lfsck test_14: ls should success

Comments

[nasf (Inactive)]

The file size should be incorrect since dangling referenced
ls: cannot access /lustre/scratch/d18d.sanity-lfsck/a1/f2: Cannot allocate memory

It is the expected result. We want to check whether the injecting dangling reference failure works or not. If not, the new size will be equal to the old one.
To avoid confusing, we can change the test scripts as:

        echo "'stat' should fail because of  dangling referenced"
        stat $DIR/$tdir/a1/f2 &&  error "(1) 'stat' file2 should fail"

[James Nunez (Inactive)]

I think you are referring to patch http://review.whamcloud.com/#/c/9004 . This issue was seen on ldiskfs and zfs, but may be a duplicate of ticket https://jira.hpdd.intel.com/browse/LU-4970 .

Also, the dangling reference does not create an incorrect file size on its own. The test creates two files of different size and then injects a failure so both files reference the same object. From a comment in the test:

Inject failure to make $DIR/$tdir/a1/f1 and $DIR/$tdir/a1/f2
to reference the same OST-object (which is f1's OST-obejct)."
Then drop $DIR/$tdir/a1/f1 and its OST-object, so f2 becomes"
dangling reference case, but f2's old OST-object is there.

[Oleg Drokin]

my question is how come a dangling reference results in incorrect file size anyway?

The cannot allocate memory is a different ticket that we have a patch for that'll land soon