From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Mon, 10 Apr 2023 22:19:46 -0700 Subject: [Cluster-devel] [PATCH v2 00/23] fs-verity support for XFS In-Reply-To: <20230404145319.2057051-1-aalbersh@redhat.com> References: <20230404145319.2057051-1-aalbersh@redhat.com> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dave is going to hate me for this, but.. I've been looking over some of the interfaces here, and I'm starting to very seriously questioning the design decisions of storing the fsverity hashes in xattrs. Yes, storing them beyond i_size in the file is a bit of a hack, but it allows to reuse a lot of the existing infrastructure, and much of fsverity is based around it. So storing them in an xattrs causes a lot of churn in the interface. And the XFS side with special casing xattr indices also seems not exactly nice. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 191A320F0 for ; Tue, 11 Apr 2023 05:19:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=6nX5sI6EN+QIsWtAaq5RhWz/W4vuyCGzISy2tTv8b6w=; b=k1nDyW9ThWdwLT7pSWirEu8vAz 5gsYJWy42X4KvcpSpeCIEbOYds8a6VmdcdtnrFfTUZOMfEQkb0BOzhlbMIm5cunipw+jcMqtf6L/r FPpApigHLGsj0AbugbMiQtHKiTFGY9ozfe/zBscnPg1Mzgw7dPOExuqFoZe1d4/QjfAIxWMa+PTwM 0e/gNRrYWpCr+ICTg8kD6Z7Kzqr7DVQAQCnWLRdiGK4HSeKC67KTJGD8gscP39JkuZlIwihkF+6hw gY+QlKY1Wbp8V4K0W3LfRl2b/hiI8yJJDxRKMbrd7FtzqjIBqzmCFNIpdbdq70XMfufV+YB7upDdm vTfdPYZg==; Received: from hch by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1pm6Py-00GReU-09; Tue, 11 Apr 2023 05:19:46 +0000 Date: Mon, 10 Apr 2023 22:19:46 -0700 From: Christoph Hellwig To: Andrey Albershteyn Cc: djwong@kernel.org, dchinner@redhat.com, ebiggers@kernel.org, hch@infradead.org, linux-xfs@vger.kernel.org, fsverity@lists.linux.dev, rpeterso@redhat.com, agruenba@redhat.com, xiang@kernel.org, chao@kernel.org, damien.lemoal@opensource.wdc.com, jth@kernel.org, linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com Subject: Re: [PATCH v2 00/23] fs-verity support for XFS Message-ID: References: <20230404145319.2057051-1-aalbersh@redhat.com> Precedence: bulk X-Mailing-List: fsverity@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230404145319.2057051-1-aalbersh@redhat.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Dave is going to hate me for this, but.. I've been looking over some of the interfaces here, and I'm starting to very seriously questioning the design decisions of storing the fsverity hashes in xattrs. Yes, storing them beyond i_size in the file is a bit of a hack, but it allows to reuse a lot of the existing infrastructure, and much of fsverity is based around it. So storing them in an xattrs causes a lot of churn in the interface. And the XFS side with special casing xattr indices also seems not exactly nice. 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D4E34C76196 for ; Tue, 11 Apr 2023 08:24:16 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Pwf5C2QvPz3cdG for ; Tue, 11 Apr 2023 18:24:15 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lists.ozlabs.org; s=201707; t=1681201455; bh=6nX5sI6EN+QIsWtAaq5RhWz/W4vuyCGzISy2tTv8b6w=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=hMtyEzOv/m6ndTva1WoIhxpMYgx+XhgtHHf7vxsusJkwijw5MVhJ3ee5E7244nkSj 3b6H7lb4hgg6xu64pdYlE+xOfP8lsgEaMsNBcIx3SKrwKivZBoR9YC+pRg3aWmf09e LQYouvpOXTjD1PpyC5g97l4+nJPrGC44yhcgXqxtnBlVbQJ3fHXKw3dR84cd0yG65P V0Gxem1eY0pvOuV5sEhyvluAu63eHVVUinTvNmyqjZHKGb7flVO7WWQ5oRxJHUrm7Z hVFZs3DvkE8PaPjGv43j9gHb7b5CHWs86afhScd4sY1Ue0ZX03WFivD24TFzgxV/k5 gNPq6fvQcnN5w== Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=bombadil.srs.infradead.org (client-ip=2607:7c80:54:3::133; helo=bombadil.infradead.org; envelope-from=batv+c6fa32d9e84a85109083+7170+infradead.org+hch@bombadil.srs.infradead.org; receiver=) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) (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 lists.ozlabs.org (Postfix) with ESMTPS id 4Pwf4z29z3z3bTG for ; Tue, 11 Apr 2023 18:23:52 +1000 (AEST) Received: from hch by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1pm6Py-00GReU-09; Tue, 11 Apr 2023 05:19:46 +0000 Date: Mon, 10 Apr 2023 22:19:46 -0700 To: Andrey Albershteyn Subject: Re: [PATCH v2 00/23] fs-verity support for XFS Message-ID: References: <20230404145319.2057051-1-aalbersh@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230404145319.2057051-1-aalbersh@redhat.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-BeenThere: linux-erofs@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development of Linux EROFS file system List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Christoph Hellwig via Linux-erofs Reply-To: Christoph Hellwig Cc: fsverity@lists.linux.dev, linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, agruenba@redhat.com, hch@infradead.org, djwong@kernel.org, damien.lemoal@opensource.wdc.com, linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com, dchinner@redhat.com, rpeterso@redhat.com, jth@kernel.org, linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org Errors-To: linux-erofs-bounces+linux-erofs=archiver.kernel.org@lists.ozlabs.org Sender: "Linux-erofs" Dave is going to hate me for this, but.. I've been looking over some of the interfaces here, and I'm starting to very seriously questioning the design decisions of storing the fsverity hashes in xattrs. Yes, storing them beyond i_size in the file is a bit of a hack, but it allows to reuse a lot of the existing infrastructure, and much of fsverity is based around it. So storing them in an xattrs causes a lot of churn in the interface. And the XFS side with special casing xattr indices also seems not exactly nice. 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 lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 65EE8C7619A for ; Tue, 11 Apr 2023 05:20:26 +0000 (UTC) Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.95) (envelope-from ) id 1pm6Qa-000367-HS; Tue, 11 Apr 2023 05:20:25 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pm6QZ-000360-HY for linux-f2fs-devel@lists.sourceforge.net; Tue, 11 Apr 2023 05:20:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=6nX5sI6EN+QIsWtAaq5RhWz/W4vuyCGzISy2tTv8b6w=; b=eYiBsl1kaQqV4+httY8Epc2Mau 9aMTlNxckgUABEPj8SYlpKrZICwIqBCxS5u2LFGiO4ZMtJo4eTGVsBPLzVskXjKJjAd9NwxX2M9oH e5OI5XVGSOWwa0mo9nPSzbc/nBmHiJsaB+0JHLBY23X9moS8ZmXTgsrWUXDoBy106jLA=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=6nX5sI6EN+QIsWtAaq5RhWz/W4vuyCGzISy2tTv8b6w=; b=kdWFGciT/pjVN15yzE4K7WzjmE snXYLekNFK3oW1zRPcOJwwTBhqVgzKGrhJTbojk3X/+yC1GqrYzHOOjuKbmDqvC7PaHt1vUHd4zhn YmbDjDf6T2905GAJU1FuHfAtxWLFja4z4F5aRsVMeSPMIFFLn19/lz7iqu8SmF5w7Qic=; Received: from bombadil.infradead.org ([198.137.202.133]) by sfi-mx-1.v28.lw.sourceforge.com with esmtps (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.95) id 1pm6QW-003lT7-1n for linux-f2fs-devel@lists.sourceforge.net; Tue, 11 Apr 2023 05:20:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=6nX5sI6EN+QIsWtAaq5RhWz/W4vuyCGzISy2tTv8b6w=; b=k1nDyW9ThWdwLT7pSWirEu8vAz 5gsYJWy42X4KvcpSpeCIEbOYds8a6VmdcdtnrFfTUZOMfEQkb0BOzhlbMIm5cunipw+jcMqtf6L/r FPpApigHLGsj0AbugbMiQtHKiTFGY9ozfe/zBscnPg1Mzgw7dPOExuqFoZe1d4/QjfAIxWMa+PTwM 0e/gNRrYWpCr+ICTg8kD6Z7Kzqr7DVQAQCnWLRdiGK4HSeKC67KTJGD8gscP39JkuZlIwihkF+6hw gY+QlKY1Wbp8V4K0W3LfRl2b/hiI8yJJDxRKMbrd7FtzqjIBqzmCFNIpdbdq70XMfufV+YB7upDdm vTfdPYZg==; Received: from hch by bombadil.infradead.org with local (Exim 4.96 #2 (Red Hat Linux)) id 1pm6Py-00GReU-09; Tue, 11 Apr 2023 05:19:46 +0000 Date: Mon, 10 Apr 2023 22:19:46 -0700 From: Christoph Hellwig To: Andrey Albershteyn Message-ID: References: <20230404145319.2057051-1-aalbersh@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20230404145319.2057051-1-aalbersh@redhat.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Headers-End: 1pm6QW-003lT7-1n Subject: Re: [f2fs-dev] [PATCH v2 00/23] fs-verity support for XFS X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: fsverity@lists.linux.dev, linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org, agruenba@redhat.com, hch@infradead.org, djwong@kernel.org, damien.lemoal@opensource.wdc.com, linux-f2fs-devel@lists.sourceforge.net, ebiggers@kernel.org, cluster-devel@redhat.com, dchinner@redhat.com, rpeterso@redhat.com, xiang@kernel.org, jth@kernel.org, linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net Dave is going to hate me for this, but.. I've been looking over some of the interfaces here, and I'm starting to very seriously questioning the design decisions of storing the fsverity hashes in xattrs. Yes, storing them beyond i_size in the file is a bit of a hack, but it allows to reuse a lot of the existing infrastructure, and much of fsverity is based around it. So storing them in an xattrs causes a lot of churn in the interface. And the XFS side with special casing xattr indices also seems not exactly nice. _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel