On Tue, Apr 09, 2019 at 10:25:14PM -0400, Tom Rini wrote:
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
Thanks. I can find error messages like: Free cluster summary wrong (144636 vs. really 144380)
So there seems to be a leak in reclaiming freed clusters.
# 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.
I'm afraid that this is not the case.
-Takahiro Akashi
-- Tom