From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Wed, 5 Apr 2023 08:48:17 -0700 Subject: [Cluster-devel] [PATCH v2 09/23] iomap: allow filesystem to implement read path verification In-Reply-To: <20230405150627.GC303486@frogsfrogsfrogs> References: <20230404145319.2057051-1-aalbersh@redhat.com> <20230404145319.2057051-10-aalbersh@redhat.com> <20230405110116.ia5wv3qxbnpdciui@aalbersh.remote.csb> <20230405150627.GC303486@frogsfrogsfrogs> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, Apr 05, 2023 at 08:06:27AM -0700, Darrick J. Wong wrote: > > > I wonder if that also makes sense and keep all the deferral in the > > > file system. We'll need that for the btrfs iomap conversion anyway, > > > and it seems more flexible. The ioend processing would then move into > > > XFS. > > > > > > > Not sure what you mean here. > > I /think/ Christoph is talking about allowing callers of iomap pagecache > operations to supply a custom submit_bio function and a bio_set so that > filesystems can add in their own post-IO processing and appropriately > sized (read: minimum you can get away with) bios. I imagine btrfs has > quite a lot of (read) ioend processing they need to do, as will xfs now > that you're adding fsverity. Exactly. > I think the point is that this is a general "check what we just read" > hook, so it could be in readpage_ops since we're never going to need to > re-validate verity contents, right? Hence it could be in readpage_ops > instead of the general iomap_folio_ops. > > Is there a use case for ->verify_folio that isn't a read post- > processing step? Yes. In fact I wonder if the verification might actually be done in the per-bio end_io handler in the file system. But I'll need to find some more time to read through the XFS parts of series to come up with a more intelligent suggestion on that.