Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp2326953rwb; Sun, 4 Sep 2022 13:26:50 -0700 (PDT) X-Google-Smtp-Source: AA6agR7JZtU3lUDLo1HX+456iv5GpH1bbJidDoQ5GQQjO1NdJxYNjkdpbYQMTSLgNlmckGGIjNd7 X-Received: by 2002:a63:5359:0:b0:41d:b5a6:23c5 with SMTP id t25-20020a635359000000b0041db5a623c5mr39003147pgl.128.1662323210497; Sun, 04 Sep 2022 13:26:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662323210; cv=none; d=google.com; s=arc-20160816; b=SfzvE0NLuEmIT99InaFbeQ3Jm0f8FDaNGqGm/tyyTvh5WpTNFoP9/PBDy6Vm+I+f87 YWDTh8UnD+fDBL7AZVjQKHkFM4e14imDNCVDb6fmM5RHMmWOX+9T7WtK7BZGnEE+eXVv lEkLBobgaPZZNzCp+YIBAku/rrJ/6HzF++VXn1BIMLs3J056qJTkt8lDWc5aenk6FKug mt/5pAzvrMaLCXuasqfSm+LCpleLNeLnveCV6ALmwWzTuWxW651E6iw+YJ/mJ/EI8nrU YIRblu+ayBrh4GM8NjO38/ToaEmFUGYLnb1GJbSTKJfunhRkfGMGeI7iXr2AiXh1dnXm vwFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-disposition:mime-version:message-id :subject:cc:to:from:date:dkim-signature; bh=o53iSUwBo85Om+P0ni62icGxGsI1yWNb5l6eiHTq1mc=; b=IOJt9cHXQINYfwXWD7RLrLT0xDSRBvDHUHp/P782clzm96cKWw5cuDn8IeRwYKEDTb kxN902IkQvy+TMAGELo3t2f7dFlGEIa2j9tT7XApIN+vQ9HHRZZ//cmsvBUQSg4k5HIP UNTE2SM0WKFcssZTvmy9ByyVE53LfBNe2Do9BeHto7AYyeGNlrugDZiOKU6aZpZ6lxrV /3zMjGmTKWcApeMhPMhEg3zPU+ChhJg21u7LPN6S1zSvfDdUJ+N7Wg4MLMShuFzqohH0 GlP3qhR85loLdujLNWAl/9e60UkdgnBlx/NRcpsxxaBbS8hnXbH/XlXA6r6wFjLbpgez 3TIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=oGYgN3oc; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l1-20020a654c41000000b0042b85da3a53si8329714pgr.473.2022.09.04.13.26.24; Sun, 04 Sep 2022 13:26:50 -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=pass header.i=@gmail.com header.s=20210112 header.b=oGYgN3oc; 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=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231225AbiIDUKA (ORCPT + 99 others); Sun, 4 Sep 2022 16:10:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230013AbiIDUJ7 (ORCPT ); Sun, 4 Sep 2022 16:09:59 -0400 Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8A9DD21E01 for ; Sun, 4 Sep 2022 13:09:57 -0700 (PDT) Received: by mail-qv1-xf33.google.com with SMTP id q8so5222944qvr.9 for ; Sun, 04 Sep 2022 13:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :from:to:cc:subject:date; bh=o53iSUwBo85Om+P0ni62icGxGsI1yWNb5l6eiHTq1mc=; b=oGYgN3ochr9DlIAyTj/i5Ku5D39MNt2W3pSWJL1Ovne5GJv2gnVULCt14k39UWbOOv zwz/atyDiGopD9GsK71qq3j+GXx1pqPgBBrzAFiB+NK3pgpY90wZO0LW3HAW7BsCu6Wu +6Ka/UeCy89vqKDRqVms0hZuAQ7Rvg51F0artV3g9bAkBswT/cSM8WXfRWveCK3EvAvZ mAfDZECebhS0wigb+DH9dUjLGYK16gMdLv9/zOzABPDNwDbate7sWmyk2cJjJqACFM1O wBMg2gXYENv4AKxBOWGUpFFYIuQr+gh1++UlGIqbXoo8MCgsge2pdM+mCfKAL70i5UX8 BbiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-disposition:mime-version:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date; bh=o53iSUwBo85Om+P0ni62icGxGsI1yWNb5l6eiHTq1mc=; b=oJ72laO3qe4COMKF9iz1VHWGOdqoJ+73xIFk4P0pHMpCcc7HQuAh1dtYkP4KckO2S/ 2LAtfLuu5NehZG9cu+8AMJcz7uhrv+1mp/d//7T0zTlcHtXlHzBMhkl4i9K9+fhotTDD B1T5T4DlLSIbPC1hL42BW+NL9q4N6KeYSrB8RBwIePhzf1A/v6biAdDVyL8hwdNOZ85j zMKoM3GFqDzUiSVRBNBrbZ4wCVtXoXI6S6YTpZOFR1lNR17yJa3CXknMJ54Mdwaj6xcO yK8hZOrIgv4B2fuE04/vHJVWZouwlGsnPiB+Bboqnhk8mcINJAbi3yAPMB1FYazbPATi ABfA== X-Gm-Message-State: ACgBeo0aWL5k2CPuwDJbYfucvHLQphoF5jv0dncBGlSjlf61OCOgXo/Z QyOi/V6wCl1eHuehDe1yM53nlCY4hUk= X-Received: by 2002:ad4:596a:0:b0:499:105:1d8f with SMTP id eq10-20020ad4596a000000b0049901051d8fmr31546607qvb.71.1662322196746; Sun, 04 Sep 2022 13:09:56 -0700 (PDT) Received: from debian-BULLSEYE-live-builder-AMD64 (h96-61-90-13.cntcnh.broadband.dynamic.tds.net. [96.61.90.13]) by smtp.gmail.com with ESMTPSA id u17-20020a05620a431100b006b9c355ed75sm6548433qko.70.2022.09.04.13.09.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 04 Sep 2022 13:09:56 -0700 (PDT) Date: Sun, 4 Sep 2022 16:09:53 -0400 From: Eric Whitney To: tytso@mit.edu Cc: linux-ext4@vger.kernel.org Subject: kvm-xfstests, adv test scenario, inode size-related failures Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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 Hi Ted: 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). 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. For reference, the tests that fail for me include: ext4/021, /036, /038, /039, /048, /271 generic/015, /077, /081, /083, /085, /204, /226, /250, /252, /371, /399, /416, /427, /449, /459, /500, /511, /619, /626 shared/298 Eric