]> git.baikalelectronics.ru Git - kernel.git/commit
btrfs: remove ordered extent check and wait during hole punching and zero range
authorFilipe Manana <fdmanana@suse.com>
Tue, 15 Mar 2022 15:22:40 +0000 (15:22 +0000)
committerDavid Sterba <dsterba@suse.com>
Mon, 16 May 2022 15:03:09 +0000 (17:03 +0200)
commit9959def25f1904f3a6724bfbc2831f11931f99a1
tree00146f6e5d39da7ded923e4909a9f31a6db8c922
parent64870efa4da0ceede634d51b130154b1c84be387
btrfs: remove ordered extent check and wait during hole punching and zero range

For hole punching and zero range we have this loop that checks if we have
ordered extents after locking the file range, and if so unlock the range,
wait for ordered extents, and retry until we don't find more ordered
extents.

This logic was needed in the past because:

1) Direct IO writes within the i_size boundary did not take the inode's
   VFS lock. This was because that lock used to be a mutex, then some
   years ago it was switched to a rw semaphore (commit 86350cd7ba55f1
   ("parallel lookups: actual switch to rwsem")), and then btrfs was
   changed to take the VFS inode's lock in shared mode for writes that
   don't cross the i_size boundary (commit de76f9c148de8f ("btrfs: use
   shared lock for direct writes within EOF"));

2) We could race with memory mapped writes, because memory mapped writes
   don't acquire the inode's VFS lock. We don't have that race anymore,
   as we have a rw semaphore to synchronize memory mapped writes with
   fallocate (and reflinking too). That change happened with commit
   71264f8cdd5600 ("btrfs: exclude mmap from happening during all
   fallocate operations").

So stop looking for ordered extents after locking the file range when
doing hole punching and zero range operations.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/file.c