From: Dave Chinner <firstname.lastname@example.org> To: David Howells <email@example.com> Cc: Amir Goldstein <firstname.lastname@example.org>, email@example.com, Jeff Layton <firstname.lastname@example.org>, David Wysochanski <email@example.com>, "Matthew Wilcox (Oracle)" <firstname.lastname@example.org>, "J. Bruce Fields" <email@example.com>, Christoph Hellwig <firstname.lastname@example.org>, Dave Chinner <email@example.com>, Alexander Viro <firstname.lastname@example.org>, email@example.com, Linux NFS Mailing List <firstname.lastname@example.org>, CIFS <email@example.com>, ceph-devel <firstname.lastname@example.org>, email@example.com, linux-fsdevel <firstname.lastname@example.org>, linux-kernel <email@example.com>, Miklos Szeredi <firstname.lastname@example.org> Subject: Re: fscache: Redesigning the on-disk cache Date: Tue, 9 Mar 2021 08:55:35 +1100 [thread overview] Message-ID: <20210308215535.GA63242@dread.disaster.area> (raw) In-Reply-To: <email@example.com> On Mon, Mar 08, 2021 at 09:13:55AM +0000, David Howells wrote: > Amir Goldstein <firstname.lastname@example.org> wrote: > > > > (0a) As (0) but using SEEK_DATA/SEEK_HOLE instead of bmap and opening the > > > file for every whole operation (which may combine reads and writes). > > > > I read that NFSv4 supports hole punching, so when using ->bmap() or SEEK_DATA > > to keep track of present data, it's hard to distinguish between an > > invalid cached range and a valid "cached hole". > > I wasn't exactly intending to permit caching over NFS. That leads to fun > making sure that the superblock you're caching isn't the one that has the > cache in it. > > However, we will need to handle hole-punching being done on a cached netfs, > even if that's just to completely invalidate the cache for that file. > > > 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. Well, that's not the big problem. The issue that makes FIEMAP unusable for determining if there is user data present in a file is that on-disk extent maps aren't exactly coherent with in-memory user data state. That is, we can have a hole on disk with delalloc user data in memory. There's user data in the file, just not on disk. Same goes for unwritten extents - there can be dirty data in memory over an unwritten extent, and it won't get converted to written until the data is written back and the filesystem runs a conversion transaction. So, yeah, if you use FIEMAP to determine where data lies in a file that is being actively modified, you're going get corrupt data sooner rather than later. SEEK_HOLE/DATA are coherent with in memory user data, so don't have this problem. Cheers, Dave. -- Dave Chinner email@example.com
next prev parent reply other threads:[~2021-03-08 21:56 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-03 23:20 David Howells 2021-03-04 13:47 ` fscache: Redesigning the on-disk cache - LRU handling David Howells 2021-03-05 9:46 ` fscache: Redesigning the on-disk cache Amir Goldstein 2021-03-08 9:13 ` David Howells 2021-03-08 10:35 ` Amir Goldstein 2021-03-08 11:28 ` Metadata writtenback notification? -- was " David Howells 2021-03-08 22:32 ` Dave Chinner 2021-03-08 23:20 ` Matthew Wilcox 2021-03-09 11:27 ` David Howells 2021-03-08 18:54 ` J. Bruce Fields 2021-03-08 19:08 ` David Howells 2021-03-08 21:55 ` Dave Chinner [this message] 2021-03-09 9:21 ` David Howells
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210308215535.GA63242@dread.disaster.area \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: fscache: Redesigning the on-disk cache' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).