| Message ID | 1511424369-28740-1-git-send-email-nborisov@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Nov 23, 2017 at 10:06:09AM +0200, Nikolay Borisov wrote: > For file extents xfs currently always calls xfs_bmapi_read with not flags, > meaning extents are going to be truncated to the requested range. This is > differs than what other filesystems do (ext4/btrfs don't trim extents). So > harmonize the behavior across the filesystem by explicitly not trimming > extents when we are called from fiemap code. Given that the iomap code generally trims extents, can you just try to always enable XFS_BMAPI_ENTIRE? -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 23.11.2017 10:15, Christoph Hellwig wrote: > On Thu, Nov 23, 2017 at 10:06:09AM +0200, Nikolay Borisov wrote: >> For file extents xfs currently always calls xfs_bmapi_read with not flags, >> meaning extents are going to be truncated to the requested range. This is >> differs than what other filesystems do (ext4/btrfs don't trim extents). So >> harmonize the behavior across the filesystem by explicitly not trimming >> extents when we are called from fiemap code. > > Given that the iomap code generally trims extents, can you just try > to always enable XFS_BMAPI_ENTIRE? What you are saying is that iomap currently always trims the returned range from the underlying filesystem so doing trimming in the fs is redundant and I can just pass XFS_BMAPI_ENTIRE indiscriminately ? > -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 23, 2017 at 10:28:39AM +0200, Nikolay Borisov wrote: > What you are saying is that iomap currently always trims the returned > range from the underlying filesystem so doing trimming in the fs is > redundant and I can just pass XFS_BMAPI_ENTIRE indiscriminately ? I think so. But the theory needs proper valiation first, so please do a full test run with that change. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 23.11.2017 10:30, Christoph Hellwig wrote: > On Thu, Nov 23, 2017 at 10:28:39AM +0200, Nikolay Borisov wrote: >> What you are saying is that iomap currently always trims the returned >> range from the underlying filesystem so doing trimming in the fs is >> redundant and I can just pass XFS_BMAPI_ENTIRE indiscriminately ? > > I think so. But the theory needs proper valiation first, so please > do a full test run with that change. > Right, so no new failures introduced by always passing XFS_BMAP_ENTIRE so I will resend the patch. -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index f179bdf1644d..129550fbf898 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -1008,7 +1008,8 @@ xfs_file_iomap_begin( end_fsb = XFS_B_TO_FSB(mp, offset + length); error = xfs_bmapi_read(ip, offset_fsb, end_fsb - offset_fsb, &imap, - &nimaps, 0); + &nimaps, + flags & IOMAP_REPORT ? XFS_BMAPI_ENTIRE : 0); if (error) goto out_unlock;
For file extents xfs currently always calls xfs_bmapi_read with not flags, meaning extents are going to be truncated to the requested range. This is differs than what other filesystems do (ext4/btrfs don't trim extents). So harmonize the behavior across the filesystem by explicitly not trimming extents when we are called from fiemap code. Signed-off-by: Nikolay Borisov <nborisov@suse.com> --- fs/xfs/xfs_iomap.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)