[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210308185410.GE7284@fieldses.org>
Date: Mon, 8 Mar 2021 13:54:10 -0500
From: "J. Bruce Fields" <bfields@...ldses.org>
To: David Howells <dhowells@...hat.com>
Cc: Amir Goldstein <amir73il@...il.com>, linux-cachefs@...hat.com,
Jeff Layton <jlayton@...hat.com>,
David Wysochanski <dwysocha@...hat.com>,
"Matthew Wilcox (Oracle)" <willy@...radead.org>,
Christoph Hellwig <hch@...radead.org>,
Dave Chinner <dchinner@...hat.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
linux-afs@...ts.infradead.org,
Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
CIFS <linux-cifs@...r.kernel.org>,
ceph-devel <ceph-devel@...r.kernel.org>,
v9fs-developer@...ts.sourceforge.net,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Miklos Szeredi <miklos@...redi.hu>
Subject: Re: fscache: Redesigning the on-disk cache
On Mon, Mar 08, 2021 at 09:13:55AM +0000, David Howells wrote:
> Amir Goldstein <amir73il@...il.com> 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 Dave's
> assertion is that the cache can't rely on the backing filesystem's metadata
> because these can arbitrarily insert or remove blocks of zeros to bridge 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?
--b.
Powered by blists - more mailing lists