LTP: fix test case issue sync_file_range02 issue #66
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
After the PR: lsds/sgx-lkl#750 one of the sub test case is failing and upsteam repo change 1643d85 fixes the issue. Hence, propagating the fix.
shaikshavali1
added a commit
to shaikshavali1/sgx-lkl
that referenced
this pull request
Aug 11, 2020
This test case causing oom killer to be invoked and causing kernel panic. This is because the test case invokes test framework function "tst_acquire_device" which creates a 256MB of .img file and binds with a loop device. This is not supported because the default size of LKL memory is set to 32M. This is kept low due to the limited size of EPC (Enclave page cache) and to avoid page cache being swapped out. Also, the test case invokes "tst_mkfs" framework function which inturn invokes mkfs utility command with the help of system() syscall. It is recommended to use root file system, but, this test case needs a read-only filesystem to test one of the sub-test cases. we don't have a read-only file system mounted in sgx-lkl. To support the test cases which need a block device a formatted ext4 filesystem image created and passed to enclave as extended disk. The test case passes the details about this new block disk image in the application configuration file. The test framework will pick this image details in the environment variable and use it in test. Test case changes link: lsds/ltp#49, lsds/ltp#59, lsds/ltp#65, lsds/ltp#66.
|
There should be some comments explaining the patch. |
Description from upstream commit.
Test tries to sync a range of $BYTES bytes, and then makes sure that
between $BYTES and $BYTES+10% was written to disk. But sometimes, more
than $BYTES+10% hit the disk: "Synced 39843840, expected 33554432" so
it failed as below.
tst_test.c:1179: INFO: Testing on ext4
sync_file_range02.c:74: FAIL: Sync equals write: Synced 39843840,
expected 33554432
sync_file_range02.c:74: FAIL: Sync inside of write: Synced 18612224,
expected 16777216
From FS dev's view:
" ext4 defers a lot of IO on a freshly made filesystem to the kernel -
for example it will initialize the journal and inode tables after the
mount, and this will cause extra IO.
Creating ext4 filesystems with the options: "-E lazy_itable_init=0,
lazy_journal_init=0" might help.
Another option would be to raise the threshold. Essentially, the report
here is that the test is failing because the filesystem wrote "too much"
as a result of the sync. How much is "too much?" ..."
Let's remove the toplimit of write back, and think as long as we synced
at least the expected amount, the test passes. The +10% limit seems arbitrary.
davidchisnall
approved these changes
Aug 12, 2020
This was referenced Aug 12, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After the PR: lsds/sgx-lkl#764
one of the subtest cases is failing and LTP master branch
change fixes the issue. Hence, propagating the fix.
Please find below the description from the upstream commit.
Test tries to sync a range of $BYTES bytes and then make sure that
between $BYTES and $BYTES+10% was written to disk. But sometimes, more
than $BYTES+10% hit the disk: "Synced 39843840, expected 33554432" so
it failed as below.
tst_test.c:1179: INFO: Testing on ext4
sync_file_range02.c:74: FAIL: Sync equals write: Synced 39843840,
expected 33554432
sync_file_range02.c:74: FAIL: Sync inside of write: Synced 18612224,
expected 16777216
From FS dev's view:
" ext4 defers a lot of IO on a freshly made filesystem to the kernel -
for example, it will initialize the journal and inode tables after the
mount and this will cause extra IO.
Creating ext4 filesystems with the options: "-E lazy_itable_init=0,
lazy_journal_init=0" might help.
Another option would be to raise the threshold. Essentially, the report
here is that the test is failing because the filesystem wrote "too much"
as a result of the sync. How much is "too much?" ..."
Let's remove the top limit of write back, and think as long as we synced
at least the expected amount, the test passes. The +10% limit seems arbitrary.