
On Wed, Apr 10, 2019 at 10:37:42AM +0900, Takahiro Akashi wrote:
On Tue, Apr 09, 2019 at 08:19:40PM -0400, Tom Rini wrote:
On Wed, Apr 10, 2019 at 02:10:12AM +0200, Heinrich Schuchardt wrote:
On 4/9/19 10:03 PM, Tom Rini wrote:
On Wed, Feb 13, 2019 at 12:15:23PM +0100, Jean-Jacques Hiblot wrote:
We need to make sure that file writes,file creation, etc. are properly performed and do not corrupt the filesystem. To help with this, introduce the assert_fs_integrity() function that executes the appropriate fsck tool. It should be called at the end of any test that modify the content/organization of the filesystem. Currently only supports FATs and EXT4.
Signed-off-by: Jean-Jacques Hiblot jjhiblot@ti.com Reviewed-by: Tom Rini trini@konsulko.com
OK, I'm adding in a bunch of people to CC here. The issue with this patch is that by adding fsck to our tests we see 34 FAT16/FAT32 failures: TestFsBasic.test_fs13[fat16] TestFsBasic.test_fs11[fat32] TestFsBasic.test_fs12[fat32] TestFsBasic.test_fs13[fat32] TestFsExt.test_fs_ext1[fat32] TestFsExt.test_fs_ext2[fat32] TestFsExt.test_fs_ext3[fat32] TestFsExt.test_fs_ext4[fat32] TestFsExt.test_fs_ext5[fat32] TestFsExt.test_fs_ext6[fat32] TestFsExt.test_fs_ext7[fat32] TestFsExt.test_fs_ext8[fat32] TestFsExt.test_fs_ext9[fat32] TestMkdir.test_mkdir6[fat16] TestMkdir.test_mkdir1[fat32] TestMkdir.test_mkdir2[fat32] TestMkdir.test_mkdir3[fat32] TestMkdir.test_mkdir4[fat32] TestMkdir.test_mkdir5[fat32] TestMkdir.test_mkdir6[fat32] TestUnlink.test_unlink1[fat16] TestUnlink.test_unlink2[fat16] TestUnlink.test_unlink3[fat16] TestUnlink.test_unlink4[fat16] TestUnlink.test_unlink5[fat16] TestUnlink.test_unlink6[fat16] TestUnlink.test_unlink7[fat16] TestUnlink.test_unlink1[fat32] TestUnlink.test_unlink2[fat32] TestUnlink.test_unlink3[fat32] TestUnlink.test_unlink4[fat32] TestUnlink.test_unlink5[fat32] TestUnlink.test_unlink6[fat32] TestUnlink.test_unlink7[fat32]
I appreciate that we get tests for file system functions.
Unfortunately the test output is rudimentary. Can we have something more expressive than unlink1 - unlink7?
CCing Takahiro as he was contributing recently to FAT.
Sorry, yes, kind of? I pasted that in for brevity, but it's basically that for example all of test/py/tests/test_fs/test_unlink.py fails if you fsck the image in question after each test. If you apply https://patchwork.ozlabs.org/patch/1041186/ (to avoid spurious ext4 failures) and then https://patchwork.ozlabs.org/patch/1041181/ and run 'make tests' you'll see the full output.
I have no time to dig into this issue right now, but if you give me a log from fsck, particularly why fsck failed here, it would help me to understand the problem.
The raw log can be seen here: https://gist.github.com/trini/b68799ed9880a31a3289e9bea033831d
# like the case of ext4, we might have to turn off # some option at fsck?
Note that for ext4 we're turning off the metadata csum feature of the filesystem as we do not support it.