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 X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E24A0C43381 for ; Mon, 8 Mar 2021 19:10:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AFD4064EEA for ; Mon, 8 Mar 2021 19:10:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229701AbhCHTJd (ORCPT ); Mon, 8 Mar 2021 14:09:33 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:27817 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229650AbhCHTJE (ORCPT ); Mon, 8 Mar 2021 14:09:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615230543; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pBhajOJHrx3P1bFfpTnaW+JD8S792IZZwlNpIQC5Q0g=; b=Wa4JJmEsSW657KZboi0NuNYCQXrcQKQCtgdmsY34DNdoKDodEQNsFhO+K82qcz6gnXw3Am bYFm5nlw2LlXa7zv3+yRNJKop2+0AW3SkmncBdXUTIvmnY6QEqvJD0OH5QYAXX3wWi5faE px3MGm5oi5ZdKAjrcO5E9eXxvseaqnQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-285-mfpi1OsCPjKSNXMW3mY4Qw-1; Mon, 08 Mar 2021 14:09:02 -0500 X-MC-Unique: mfpi1OsCPjKSNXMW3mY4Qw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E8114801814; Mon, 8 Mar 2021 19:08:59 +0000 (UTC) Received: from warthog.procyon.org.uk (ovpn-118-152.rdu2.redhat.com [10.10.118.152]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9B45F19C79; Mon, 8 Mar 2021 19:08:53 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <20210308185410.GE7284@fieldses.org> References: <20210308185410.GE7284@fieldses.org> <2653261.1614813611@warthog.procyon.org.uk> <517184.1615194835@warthog.procyon.org.uk> To: "J. Bruce Fields" Cc: dhowells@redhat.com, Amir Goldstein , linux-cachefs@redhat.com, Jeff Layton , David Wysochanski , "Matthew Wilcox (Oracle)" , Christoph Hellwig , Dave Chinner , Alexander Viro , linux-afs@lists.infradead.org, Linux NFS Mailing List , CIFS , ceph-devel , v9fs-developer@lists.sourceforge.net, linux-fsdevel , linux-kernel , Miklos Szeredi Subject: Re: fscache: Redesigning the on-disk cache MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19638.1615230532.1@warthog.procyon.org.uk> Content-Transfer-Encoding: quoted-printable Date: Mon, 08 Mar 2021 19:08:52 +0000 Message-ID: <19639.1615230532@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org J. Bruce Fields wrote: > On Mon, Mar 08, 2021 at 09:13:55AM +0000, David Howells wrote: > > Amir Goldstein wrote: > > > With ->fiemap() you can at least make the distinction between a non = existing > > > and an UNWRITTEN extent. > > = > > I can't use that for XFS, Ext4 or btrfs, I suspect. Christoph and Dav= e's > > assertion is that the cache can't rely on the backing filesystem's met= adata > > because these can arbitrarily insert or remove blocks of zeros to brid= ge or > > split extents. > = > Could you instead make some sort of explicit contract with the > filesystem? Maybe you'd flag it at mkfs time and query for it before > allowing a filesystem to be used for fscache. You don't need every > filesystem to support fscache, right, just one acceptable one? I've asked about that, but the filesystem maintainers are reluctant to do that. Something might be possible in ext4 using direct access to jbd2, though I don't know exactly what facilities that offers. David