Re: [U-Boot] [U-Boot, RESEND, v5, 3/7] test: fs: Add filesystem integrity checks
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 > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, v5, 3/7] test: fs: Add filesystem integrity checks
On Wed, Apr 10, 2019 at 11:51:20AM +0900, Takahiro Akashi wrote: > 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 > > > > > >> Reviewed-by: Tom Rini > > > > > > > > > > > > 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. A count of free clusters, along with other info, is kept in an "info sector" on a file system (only for fat32), but in U-Boot fat, none of information in that sector is currently maintained. So this error would be inevitable. I don't know any fsck option to suppress this kind of check. -Takahiro Akashi > > > # 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 > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, v5, 3/7] test: fs: Add filesystem integrity checks
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 > > > > >> Reviewed-by: Tom Rini > > > > > > > > > > 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, v5, 3/7] test: fs: Add filesystem integrity checks
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 > > > >> Reviewed-by: Tom Rini > > > > > > > > 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. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, v5, 3/7] test: fs: Add filesystem integrity checks
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 > > >> Reviewed-by: Tom Rini > > > > > > 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. # like the case of ext4, we might have to turn off # some option at fsck? Thanks, -Takahiro Akashi > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, v5, 3/7] test: fs: Add filesystem integrity checks
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 > >> Reviewed-by: Tom Rini > > > > 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. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, v5, 3/7] test: fs: Add filesystem integrity checks
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 >> Reviewed-by: Tom Rini > > 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. Best regards Heinrich > > So... I'm inclined to say that to start with, I bring this patch in and > then disable FAT fsck (as I cannot see how to mark these as xfail with > a comment that we need to fix them, only for FAT). But we should get > these FAT problems fixed. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, RESEND, v5, 3/7] test: fs: Add filesystem integrity checks
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 > Reviewed-by: Tom Rini 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] So... I'm inclined to say that to start with, I bring this patch in and then disable FAT fsck (as I cannot see how to mark these as xfail with a comment that we need to fix them, only for FAT). But we should get these FAT problems fixed. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
