From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EE437C00144 for ; Mon, 1 Aug 2022 06:14:24 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id AEF5884405; Mon, 1 Aug 2022 08:14:22 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=canonical.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=canonical.com header.i=@canonical.com header.b="Uo/0lGFz"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 89D6F84409; Mon, 1 Aug 2022 08:14:21 +0200 (CEST) Received: from smtp-relay-internal-0.canonical.com (smtp-relay-internal-0.canonical.com [185.125.188.122]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 14A7084137 for ; Mon, 1 Aug 2022 08:14:19 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=canonical.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=heinrich.schuchardt@canonical.com Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-0.canonical.com (Postfix) with ESMTPS id 2272D3F125 for ; Mon, 1 Aug 2022 06:14:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=canonical.com; s=20210705; t=1659334458; bh=2GvQSVHOq4IKBe+fJpmkbQ9Ja/U0oqiyQi1MDGC0lJ8=; h=Message-ID:Date:MIME-Version:Subject:To:References:From:Cc: In-Reply-To:Content-Type; b=Uo/0lGFzusN6V570mjKQX+QSag9t7H2kl6KexTE+7JNngTsvfS57kbQInviaplO4b wf9MW3zXrs7Y7Yi3iFOT8ZR4QbMpWdSTHh6FlJpnloKQqumJglG00WBqQ2X116IdCB t4DFOsssVXTVSzjdu7V8y8XSIz5M8uuL4W1wx1z7epaNWvGM8Q0fsY1tnXaN7rPeSy gf9Mj+1IsLGnGBQi4OAC8AnBa4ln45seyRK1kTkfjvR+LyiJjF9S7HQH1JJapBniVA gRKzDWDBb6b0iVAzqAAxhsUB+JxtVkHh7jkN+cRNbPeRny373nBPa/AmszQlU3xaQ9 WEY8d1PzNh9Sg== Received: by mail-wr1-f72.google.com with SMTP id n7-20020adfc607000000b0021a37d8f93aso2233260wrg.21 for ; Sun, 31 Jul 2022 23:14:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :to:references:content-language:from:cc:in-reply-to :content-transfer-encoding; bh=2GvQSVHOq4IKBe+fJpmkbQ9Ja/U0oqiyQi1MDGC0lJ8=; b=aaRXnFNI1PzSSbL3FSYErVMuJspcstoFgbVuRSrsODROlAKgBkOlCZxKA2dF93kX4r hmm7RL5h/wEVgFbIb1BcfjrOWqSAu2VAIvL46QVKODBwzQ2BimPeXxPU9OP6y9W/vrga udEpTQ5EwAx2ooJhuX7RaqnGipaHGZZwkaWXZXVOmGWVTTygnD8GfoeH+huL07VK2FAQ up+9eiIw2DffWGC6BMxKpoY1DQbJhrgEa/lcQAfdNjBHNqelXo8WGrzPi5xHI6PVquyB wU7oXYkb9p74xVq37V0yctpWXkwZ96DPkdPZcGTm94w2H9O8PIaT1Vz/vwH8c5hZM+aU gL1g== X-Gm-Message-State: AJIora+e2h2x9oLy6qJZx+mtG0C7gXVytAFTDyvzbSIr69L/J4s/LLR2 NWTrRmmmVx9rvwe1u55sNR5aHN1vFE+RQocLfW5uWTYN2vZ7mXkX75QhrCx6RGtgGUZuqWRmPK5 KfuA8ubJKTPT7Tdf3AhZm1swSrNGnYNg= X-Received: by 2002:a05:600c:1986:b0:3a3:490b:1fd4 with SMTP id t6-20020a05600c198600b003a3490b1fd4mr9748504wmq.140.1659334457373; Sun, 31 Jul 2022 23:14:17 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uQ6JNq3Mf2oR8w25HWs1j2MQOpwpT2992Czh9fWjM0Ra6i1oSjYe6nLivteZ6huKEyxpCY6w== X-Received: by 2002:a05:600c:1986:b0:3a3:490b:1fd4 with SMTP id t6-20020a05600c198600b003a3490b1fd4mr9748496wmq.140.1659334457077; Sun, 31 Jul 2022 23:14:17 -0700 (PDT) Received: from [192.168.123.94] (ip-062-143-094-109.um16.pools.vodafone-ip.de. [62.143.94.109]) by smtp.gmail.com with ESMTPSA id t18-20020a05600c199200b003a3278d5cafsm19492375wmq.28.2022.07.31.23.14.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 31 Jul 2022 23:14:16 -0700 (PDT) Message-ID: Date: Mon, 1 Aug 2022 08:14:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.1.0 Subject: Re: [PATCH v2 5/5] test: add test for full FAT16 directory To: AKASHI Takahiro References: <20220731115837.77646-1-heinrich.schuchardt@canonical.com> <20220731115837.77646-6-heinrich.schuchardt@canonical.com> <20220801015057.GB37247@laputa> Content-Language: en-US From: Heinrich Schuchardt Cc: Tom Rini , u-boot@lists.denx.de In-Reply-To: <20220801015057.GB37247@laputa> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean 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. Creating the maximum 512 directory entries for the root directory of FAT16 can be done in a reasonable time. 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. The 2 MiB limit is not implemented in U-Boot. So the test would fail after a few days or weeks. > >> Signed-off-by: Heinrich Schuchardt >> --- >> 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 >>