public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: Tom Rini <trini@konsulko.com>, u-boot@lists.denx.de
Subject: Re: [PATCH v2 5/5] test: add test for full FAT16 directory
Date: Tue, 2 Aug 2022 09:19:56 +0900	[thread overview]
Message-ID: <20220802001956.GB53591@laputa> (raw)
In-Reply-To: <d82779ad-5bd8-4ff0-17bd-9f5edebfe4ad@canonical.com>

On Mon, Aug 01, 2022 at 08:14:15AM +0200, Heinrich Schuchardt wrote:
> 
> 
> On 8/1/22 03:50, AKASHI Takahiro wrote:
> > On Sun, Jul 31, 2022 at 01:58:37PM +0200, Heinrich Schuchardt wrote:
> > > Add a unit test checking that a full FAT16 directory leads to an error
> > > when trying to add an additional entry.
> > 
> > Thank you for adding this test case, but
> > why do you restrict this test to fat16 and the root directory?
> > The root directory on fat16 is a very much special case and differently
> > implemented from others. So the test scenario doesn't do what we expect
> > for fulfilling the whole disk.
> > 
> > I think we should use other sub directories (and other file systems as well).
> 
> No other filesystem but FAT supports mkdir in U-Boot currently.

Right, but it won't prevent us from creating a generic test scenario.
My pytest already has a mechanism to run a test for a specific set of
file systems. See supported_fs_xxx.

> Creating the maximum 512 directory entries for the root directory of FAT16
> can be done in a reasonable time.

As I said, the root directory on fat16 is very special and has a fixed size
of blocks and using it in your test will *never* make the file system full.

> Otherwise "The maximum valid directory size is 2**21 bytes." Creating 65536
> entries takes far too long to be done in a regular test. Even a bash script
> in Linux needs more than half an hour for this on my laptop.

Providing a test and running it is different things.
If necessary, we should exercise it.

> The 2 MiB limit is not implemented in U-Boot. So the test would fail after a
> few days or weeks.

If so, why not fix the problem?

-Takahiro Akashi

> 
> > 
> > > Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> > > ---
> > > v2:
> > > 	new patch
> > > ---
> > >   test/py/tests/test_fs/test_mkdir.py | 17 +++++++++++++++++
> > >   1 file changed, 17 insertions(+)
> > > 
> > > diff --git a/test/py/tests/test_fs/test_mkdir.py b/test/py/tests/test_fs/test_mkdir.py
> > > index f5cc308362..e3a9e3ed27 100644
> > > --- a/test/py/tests/test_fs/test_mkdir.py
> > > +++ b/test/py/tests/test_fs/test_mkdir.py
> > > @@ -119,3 +119,20 @@ class TestMkdir(object):
> > >               assert('0123456789abcdef00/'  in output)
> > >               assert('0123456789abcdef13/'  in output)
> > >               assert_fs_integrity(fs_ubtype, fs_img)
> > > +
> > > +    def test_mkdir7(self, u_boot_console, fs_obj_mkdir):
> > > +        """ Test Case 7 - max out number of root directory entries
> > > +        """
> > > +        _, _, fs_type = fs_obj_mkdir
> > 
> > Why not use fs_ubtype, _, fs_type = ..., then
> > 
> > > +        if fs_type != 'fat16':
> > > +            return
> > > +        with u_boot_console.log.section('Test Case 7 - mkdir (max out)'):
> > > +            for i in range(0, 512):
> > > +                output = u_boot_console.run_command(
> > > +                    f'fatmkdir host 0:0 /U-Boot-mkdir-max-out-test-directory-{i:05d}')
> > 
> > '%smkdir ...'.format(fs_ubtype, i)
> 
> We know it is FAT.
> 
> Best regards
> 
> Heinrich
> > 
> > -Takahiro Akashi
> > 
> > > +                if 'Can\'t create directory entry' in output:
> > > +                    break
> > > +            # A directory was created
> > > +            assert i > 0
> > > +            # The FAT16 root directory has only 512 directory entries
> > > +            assert i <= 512 / 5
> > > -- 
> > > 2.36.1
> > > 

      reply	other threads:[~2022-08-02  0:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-31 11:58 [PATCH v2 0/5] fs/fat: fix handling of full disk Heinrich Schuchardt
2022-07-31 11:58 ` [PATCH v2 1/5] fs: fat: finding an empty FAT cluster Heinrich Schuchardt
2022-08-01  1:02   ` AKASHI Takahiro
2022-08-01  8:21     ` Heinrich Schuchardt
2022-08-02  0:02       ` AKASHI Takahiro
2022-07-31 11:58 ` [PATCH v2 2/5] fs: fat: determine_fatent() error handling Heinrich Schuchardt
2022-07-31 11:58 ` [PATCH v2 3/5] fs: fat: carve out fat_create_dir_entry() Heinrich Schuchardt
2022-07-31 11:58 ` [PATCH v2 4/5] test: let fs_obj_mkdir() provide full file system type Heinrich Schuchardt
2022-07-31 11:58 ` [PATCH v2 5/5] test: add test for full FAT16 directory Heinrich Schuchardt
2022-08-01  1:50   ` AKASHI Takahiro
2022-08-01  6:14     ` Heinrich Schuchardt
2022-08-02  0:19       ` AKASHI Takahiro [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220802001956.GB53591@laputa \
    --to=takahiro.akashi@linaro.org \
    --cc=heinrich.schuchardt@canonical.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox