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 DD69FC00144 for ; Tue, 2 Aug 2022 00:20:09 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 99B6F8300F; Tue, 2 Aug 2022 02:20:07 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org 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=linaro.org header.i=@linaro.org header.b="Nm4zALqZ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id C0C7783AD1; Tue, 2 Aug 2022 02:20:05 +0200 (CEST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 4BEC080756 for ; Tue, 2 Aug 2022 02:20:02 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=takahiro.akashi@linaro.org Received: by mail-pg1-x529.google.com with SMTP id 23so11012843pgc.8 for ; Mon, 01 Aug 2022 17:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date:from:to:cc; bh=G7K7Wc9pgpWmS+VLaA0B6sdaTwGo71IJAxUVDKLp6eY=; b=Nm4zALqZ3hrWy1JokOhwWBfW8l6b3sOduwnQl1iCpjw0vvRdNEnWYS4zqFi4cziuRQ j0pVF7y7HMtbxKxh3XDG6GQnNzNNBHi2G5yuEAihvXC2lcTmZvtfRnny6xCkg+awNir0 yPnRIxq3S5xuRS1ZTd9WSLxzN/Iy+v5SbxaauDPoNWKJPAjUkkeqNFcrfqjEcuwwf/UQ y4zccmcWK6zqUPN0YDczWEK4VQSiNwaJDtTsIJZashiNq0pmQIjf9ivSHmswA5H3fHPQ bxEhxBIY9J4l1DZvCvb/QySYk5tNRFVOEspVAo2d0kEbRSIe3g46+16tPjeXecxa9Aww L0Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc; bh=G7K7Wc9pgpWmS+VLaA0B6sdaTwGo71IJAxUVDKLp6eY=; b=fS2NwqQYzoCnYJYivfDP3WmPbiFCNxUjA+NWHmoRRd7XXvcj+iMdROHyBNN1o3/J8d cYTirAMlusVck94DbctyACwG8Kn6qIlhmVfmWL43MK9rzL6TdnDP2ea85a3lq15w0som +i6eTmTHPM7UALOtQ/VHMZ9gr7k1udw0tepWxJzKD/ksOXHOBGnDSE844YxILSxP1cXt 4ietsVM0LNAksAlUffgsUq908lELRVO+cUZTj+g+LsIp/N98ZYq3q64ISVJAT3ONR6yj yTJ6kSONqAH5xTXDyU1v75/4AKUHwu23Ir0nSQanrgGVfvgpLCAoHaryN+Eac9+/Vdcq 5XJQ== X-Gm-Message-State: ACgBeo3edoyC0QYexpxe/DhgrwlhAvdCPeiPHgkZoYUrhWG7uOiA5ye6 +FbuEEqOeDRKO/n/M3gWbTdQtw== X-Google-Smtp-Source: AA6agR7P0F/efrszU1cBrwVCxduf7TqHVvr0xfixj3aKlcsXgbWGVmmuoCBg50Gk2/osNW6rZ7+rOQ== X-Received: by 2002:a65:4605:0:b0:41c:3d73:9385 with SMTP id v5-20020a654605000000b0041c3d739385mr3211029pgq.168.1659399600504; Mon, 01 Aug 2022 17:20:00 -0700 (PDT) Received: from laputa ([2400:4050:c3e1:100:4407:5475:fc77:828c]) by smtp.gmail.com with ESMTPSA id a13-20020aa7970d000000b0052aaf7fdf2esm9191867pfg.137.2022.08.01.17.19.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Aug 2022 17:19:59 -0700 (PDT) Date: Tue, 2 Aug 2022 09:19:56 +0900 From: AKASHI Takahiro To: Heinrich Schuchardt Cc: Tom Rini , u-boot@lists.denx.de Subject: Re: [PATCH v2 5/5] test: add test for full FAT16 directory Message-ID: <20220802001956.GB53591@laputa> Mail-Followup-To: AKASHI Takahiro , Heinrich Schuchardt , Tom Rini , u-boot@lists.denx.de References: <20220731115837.77646-1-heinrich.schuchardt@canonical.com> <20220731115837.77646-6-heinrich.schuchardt@canonical.com> <20220801015057.GB37247@laputa> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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 > > > --- > > > 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 > > >