On Mon, Jun 26, 2017 at 11:50 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > On Fri, Jun 23, 2017 at 03:34:38PM +0200, Andreas Gruenbacher wrote: >> These patches, on top of the page_cache_seek_hole_data patches posted earlier >> today, convert xfs to implement SEEK_HOLE / SEEK_DATA via iomap, and implement >> SEEK_HOLE / SEEK_DATA via iomap in gfs2. > > Please send those as one series - in fact to me the previous > series doesn't even make sense - just introduce page_cache_seek_hole_data > for the iomap code only as everyone should be using that. > >> ext4 doesn't implement IOMAP_REPORT, so it can't be switched to use the iomap >> based SEEK_HOLE / SEEK_DATA or fiemap code so far. > > Just treat it as a no-op, it only really matters for the reflink case. I'm actually not sure what you're talking about. The page_cache_seek_hole_data patches fix a bug in the lseek implementations of xfs and ext4. We want those bugs to be fixed on both filesystems. On ext4, we cannot switch to iomap_seek_hole_data because ext4 doesn't implement IOMAP_REPORT. We also cannot fall back to a dummy IOMAP_REPORT function that reports the whole file as data because that would be a regression -- after all, ext4 supports lseek SEEK_HOLE / SEEK_DATA already. We could squash the two xfs patches together, but __xfs_seek_hole_data can only be removed once your patch for cleaning up the quota code is merged, so the combined patch would convert __xfs_seek_hole_data to use page_cache_seek_hole_data and xfs_seek_hole_data to use iomap_seek_hole_data at the same time, which is a bit messy. Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
