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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78842C433F5 for ; Sat, 12 Mar 2022 02:07:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229968AbiCLCIk (ORCPT ); Fri, 11 Mar 2022 21:08:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35856 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229447AbiCLCIj (ORCPT ); Fri, 11 Mar 2022 21:08:39 -0500 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DC70B2A6D35; Fri, 11 Mar 2022 18:07:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description; bh=n8AgEWKp9LFRshxYuEwas2r7rF8fdkoMavI6bguLHYM=; b=uKQg5DPbamAXK2FBue7Sc5goqu XZk4+n7PKsHGOZRRefQsGUvV4JgleA1MsYZnzMIgebOAczaSBBNWjGpCmSnnP28gnne1hwWtPD7lv JK8aPobIN+Nmy/jt6j4ZHQ/1JqxtHRl++6rb1/PKSKUL/MNsmbUmj54OMiZQE1iC+jxHDe2FuS3TS KPzKUA1fz6P0vCVmDpYhSNjmrAERaM71j1Cg0Wqqb9aRhm6RLPfBWlvIsbZE83pDsCDzt8T7RUQ42 A2BHjfmsE93BplkYybzotaH9tlkZWyokZqaoLCWodaEL3DFAYz7q2O0v5WU9Cf/l1ZPMyXAgWUMsb 9S6WTd9g==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nSrA9-000ZN5-9H; Sat, 12 Mar 2022 02:07:21 +0000 Date: Fri, 11 Mar 2022 18:07:21 -0800 From: Luis Chamberlain To: Josef Bacik , David Sterba Cc: Theodore Ts'o , Greg KH , Amir Goldstein , Sasha Levin , lsf-pc , linux-btrfs@vger.kernel.org, linux-fsdevel , Jan Kara , "Darrick J. Wong" , Matthew Wilcox , Goldwyn Rodrigues , Pankaj Raghav , Javier =?iso-8859-1?Q?Gonz=E1lez?= , Damien Le Moal , Johannes Thumshirn , Chaitanya Kulkarni , Adam Manzanares , kanchan Joshi , Pankaj Raghav , Kanchan Joshi Subject: Re: [LSF/MM TOPIC] FS, MM, and stable trees Message-ID: References: <20190212170012.GF69686@sasha-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Sender: Luis Chamberlain Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Thu, Mar 10, 2022 at 01:51:22PM -0500, Josef Bacik wrote: > [root@fedora-rawhide ~]# cat /xfstests-dev/local.config > [btrfs_normal_freespacetree] > [btrfs_compress_freespacetree] > [btrfs_normal] > [btrfs_compression] > [kdave] > [btrfs_normal_noholes] > [btrfs_compress_noholes] > [btrfs_noholes_freespacetree] + linux-btrfs and zone folks. I simplified these as follows, please let me know if the names are alright. I think we may be able to come up with something more clever than btrfs_dave. The raid56/noraid56 exist just for the defaults of the distro/btrfs-progs. The expunge list is used to determine if something is raid56 or not sadly given we have no groups for putting tests into the raid56 group. The idea is some distros don't support raid56 so that is the goal with the noraid56 config. The name needs to be: $FS_$FANCY_SINGLE_SPACED_NAME Each guest spawned will have that same hostname. And likewise the expunges are collected for each guest hostname. The hostname is used to pick the expunge directory so to ensure it reflects the baseline. You may want to look at this expunge file: https://github.com/mcgrof/kdevops/blob/master/workflows/fstests/expunges/op= ensuse-leap/15.3/btrfs/unassigned/btrfs_noraid56.txt=02 [default] TEST_DEV=3D@FSTESTSTESTDEV@ TEST_DIR=3D@FSTESTSDIR@ SCRATCH_DEV_POOL=3D"@FSTESTSSCRATCHDEVPOOL@" SCRATCH_MNT=3D@FSTESTSSCRATCHMNT@ RESULT_BASE=3D$PWD/results/$HOST/$(uname -r) [btrfs_raid56] MKFS_OPTIONS=3D'-f' FSTYP=3Dbtrfs [btrfs_noraid56] MKFS_OPTIONS=3D'-f' FSTYP=3Dbtrfs [btrfs_normalfreespacetree] LOGWRITES_DEV=3D@FSTESTSLOGWRITESDEV@ MKFS_OPTIONS=3D"-K -f -O ^no-holes" MOUNT_OPTIONS=3D"-o space_cache=3Dv2" FSTYP=3Dbtrfs [btrfs_compressfreespacetree] MOUNT_OPTIONS=3D"-o compress=3Dzlib,space_cache=3Dv2" MKFS_OPTIONS=3D"-K -f -O ^no-holes" [btrfs_normal] LOGWRITES_DEV=3D@FSTESTSLOGWRITESDEV@ MKFS_OPTIONS=3D"-K -O ^no-holes -R ^free-space-tree" MOUNT_OPTIONS=3D"-o discard=3Dasync" [btrfs_compression] MOUNT_OPTIONS=3D"-o compress=3Dzstd,discard=3Dasync" MKFS_OPTIONS=3D"-K -O ^no-holes -R ^free-space-tree" [btrfs_kdave] MKFS_OPTIONS=3D"-K -O no-holes -R ^free-space-tree" MOUNT_OPTIONS=3D"-o discard,space_cache=3Dv2" [btrfs_normalnoholes] LOGWRITES_DEV=3D@FSTESTSLOGWRITESDEV@ MKFS_OPTIONS=3D"-K -O no-holes -f -R ^free-space-tree" [btrfs_compressnoholes] MKFS_OPTIONS=3D"-K -O no-holes -f -R ^free-space-tree" MOUNT_OPTIONS=3D"-o compress=3Dlzo" [btrfs_noholesfreespacetree] MKFS_OPTIONS=3D"-K -O no-holes -f" MOUNT_OPTIONS=3D"-o space_cache=3Dv2" I see nothing for NVMe ZNS.. so how about=20 [btrfs_zns] MKFS_OPTIONS=3D"-f -d single -m single" TEST_DEV=3D@FSTESTSTESTZNSDEV@ SCRATCH_DEV_POOL=3D"@FSTESTSSCRATCHDEVZNSPOOL@" [btrfs_simple] TEST_DEV=3D@FSTESTSTESTSDEV@ MKFS_OPTIONS=3D"-f -d single -m single" SCRATCH_DEV_POOL=3D"@FSTESTSSCRATCHDEVPOOL@" The idea being btrfs_simple will not use zns drives behind the scenes but btrfs_zns will. Luis