| Message ID | 20180228174552.31919-3-hch@lst.de (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
On Wed, Feb 28, 2018 at 09:45:51AM -0800, Christoph Hellwig wrote: > There is no reason to take the ilock exclusively at the start of > xfs_file_iomap_begin for direct I/O, given that it will be demoted > just before calling xfs_iomap_write_direct anyway. > > Signed-off-by: Christoph Hellwig <hch@lst.de> Seems to work fine, and reverts us back to the per-iomap behaviour. Reviewed-by: Dave Chinner <dchinner@redhat.com>
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index 4e771e0f1170..ee01859b77a5 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -965,13 +965,11 @@ static inline bool needs_cow_for_zeroing(struct xfs_bmbt_irec *imap, int nimaps) static inline bool need_excl_ilock(struct xfs_inode *ip, unsigned flags) { /* - * COW writes will allocate delalloc space, so we need to make sure - * to take the lock exclusively here. + * COW writes may allocate delalloc space or convert unwritten COW + * extents, so we need to make sure to take the lock exclusively here. */ if (xfs_is_reflink_inode(ip) && (flags & (IOMAP_WRITE | IOMAP_ZERO))) return true; - if ((flags & IOMAP_DIRECT) && (flags & IOMAP_WRITE)) - return true; return false; }
There is no reason to take the ilock exclusively at the start of xfs_file_iomap_begin for direct I/O, given that it will be demoted just before calling xfs_iomap_write_direct anyway. Signed-off-by: Christoph Hellwig <hch@lst.de> --- fs/xfs/xfs_iomap.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)