Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp3222910rwb; Mon, 5 Sep 2022 08:12:51 -0700 (PDT) X-Google-Smtp-Source: AA6agR4ITISmIlMsEMyGTLimNZenF2ZsU2RGdqZ3bzK45BhJ7Vo/VUwbAHalXEooNBqDwf8y28LA X-Received: by 2002:a05:6402:530d:b0:446:e22:cca2 with SMTP id eo13-20020a056402530d00b004460e22cca2mr43563214edb.237.1662390771279; Mon, 05 Sep 2022 08:12:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662390771; cv=none; d=google.com; s=arc-20160816; b=TRF76yE1JsKM5OEg98G5gsS5jNLE4cYVDQFnWfIccrMinvluNyz/PToTj6kDbCAaIt L/XLyaRHk2Ikx+J3H8jaD19Z9VuzYMCqm4JEEnFc5xw5INLVYMW5fCFWI72CrP4u+v1f VzvsZuBG6HDFAcWiytEQX0T4USlqV5g1zjV0jJTK51TYlloBIMg283fAswvF5BW0OwUb /rsK3YwxXNvywNbJrOHOD4OP3FAnSmqCf++4dBWXUIZZSb8AMJFUysgxpXtU8YN+MIat bkX6ejgM3/ZFsOS+AOWbB7ZyKMMCuqplfduW5wf+dYDIu00rPG9FGwR5o/9bUuuKv//0 vyfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=UwsHZn1trNyS6AcH78fSQ9WX+c0KX/jmWK2SYfFJdD8=; b=ENZDiZ68pZ5cQnWygVOZCCowyJqGnIbt6mk96O24/DaRVZeI58Bsucm54NKvMMTLb1 D5gSG1uQKWCOTdTg3sZrRALDN6cbn8YHnC7lAzVUWd4x6o9rjPhcMivVmgRvUbpwkdeq Y4fdfJrmP7Y8W2oxR1JNa7KCeFZVT3Pb6ZmP69rd6a8meDTC77BrTxFStE+PteAz2sil aFjZKlZJwDEzQd+CI/tdcdRiOuPirw5ZPhdlbNKZlWO4dmhZePiUbY1aFGzNyCRXEDGt eo0JFfiJskQfs/prndw+9qaZQrdOCIM0qasGjE6cO2URPwMA2oeXjvFOSApfbo1vAeYo xkeQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@mit.edu header.s=outgoing header.b=g7DQgMlZ; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mit.edu Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j16-20020aa7c410000000b0044e0711e3e6si3723900edq.448.2022.09.05.08.12.02; Mon, 05 Sep 2022 08:12:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=fail header.i=@mit.edu header.s=outgoing header.b=g7DQgMlZ; spf=pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mit.edu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230314AbiIEO7k (ORCPT + 99 others); Mon, 5 Sep 2022 10:59:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236825AbiIEO7j (ORCPT ); Mon, 5 Sep 2022 10:59:39 -0400 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E3E5915FD8 for ; Mon, 5 Sep 2022 07:59:36 -0700 (PDT) Received: from letrec.thunk.org (guestnat-104-133-160-99.corp.google.com [104.133.160.99] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 285ExRdu022474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 5 Sep 2022 10:59:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1662389972; bh=UwsHZn1trNyS6AcH78fSQ9WX+c0KX/jmWK2SYfFJdD8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=g7DQgMlZngE9ovkLvHaP0yaRXxdSewi+5nmvKtAhhmaNqJsgg4vQdH++txvwCwO6v luQHWgJwwZaqmkwvnqRHIhNUdMRFZ4n01Xm9VJhc8JMuADyjOYb6b3RpPlG9CRsuKB ls6aKLMEg93NzJIIka2ko1A267xh8S6zBb0xpXommpeOHTA3hCkJHIsO0xlCXAzOn0 BzYT244Zr0wMgwyezOG3W/6uHoGsyY0KFn7/basMZRCw6VixpVwtA2Sb+KQDICkn+T HSUAYgKz8wQgFWD/Qpvf5htEumEog86DgeQjN/Nr/JTqoq7YwPOkbLEdIAzvtRnNBD ZebKudUO8Q3Ug== Received: by letrec.thunk.org (Postfix, from userid 15806) id 09A628C2B62; Mon, 5 Sep 2022 10:59:27 -0400 (EDT) Date: Mon, 5 Sep 2022 10:59:27 -0400 From: "Theodore Ts'o" To: Eric Whitney Cc: linux-ext4@vger.kernel.org Subject: Re: kvm-xfstests, adv test scenario, inode size-related failures Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Sun, Sep 04, 2022 at 04:09:53PM -0400, Eric Whitney wrote: > > I'm seeing a large number of test failures running 6.0-rc3 on the latest > version of the test appliance in the adv test scenario. All of these failures > share a common feature - mke2fs fails to create a scratch file system using the > inline option because the requested inode size is 128 bytes. This didn't > occur on the previous version of the test appliance. > > It looks like /etc/mke2fs.conf contains an extra relation for the "small" > stanza: "inode_size = 128". This isn't present in mke2fs.conf in the > previous version of the test appliance, nor does it appear to be in the latest > master branch version of e2fsprogs (perhaps I'm looking in the wrong place).... Whoops, thanks for reporting this. What happened was that in the previous version of the test apppliance, we were using a test version of e2fsprogs which was built from master branch. I built the kvm-xfstests images on a new build system, and it was missing the bleedging-edge versions of e2fsprogs in the override debs directory, so the image was using the Debian Stable (Bullseye) version of e2fsprogs which is based on 1.46.2. The Bullseyes/Backport version of e2fsprogs is based on 1.46.5 and it would work fine. Unfortunately, the package list for gce-xfstests and kvm-xfstests are specified spearately, and while I had forced gce-xfstests to use the backports version for e2fsprogs, I hadn't done so for kvm-xfstests. > Deleting that line from /etc/mke2fs.conf on the latest version of the test > appliance eliminates the failures (as does modifying ~/fs/ext4/conf/adv > to specify a 256 byte inode size in the list of mkfs options). The previous > version of the test appliance applied the default mke2fs.conf value of 256 > for the inode size, so mke2fs didn't reject the request there. I've fixed this in xfstests-bld: commit 23020e266941c73928563554627a713d92462e70 Author: Theodore Ts'o Date: Mon Sep 5 09:10:46 2022 -0400 test-appliance: install e2fsprogs from bullseye/backports in kvm-xfstests Signed-off-by: Theodore Ts'o But if you can just use the workaround of using "kvm-xfstests maint" to edit the /etc/mke2fs.conf file, that's probably the best short-term solution, since I hope to re-release new test appliances with the latest e2fsprogs 1.46.0-rc0 shortly. This will enable the "adv2" test case, and ultimately, once we get 1.46.0 into bullseye/backports, I'll probably change the adv test case to include the orphan_file feature and make adv2 an alias for adv. Cheers, - Ted