]> git.baikalelectronics.ru Git - kernel.git/commit
btrfs: remove ordered extent check and wait during fallocate
authorFilipe Manana <fdmanana@suse.com>
Tue, 15 Mar 2022 15:22:38 +0000 (15:22 +0000)
committerDavid Sterba <dsterba@suse.com>
Mon, 16 May 2022 15:03:09 +0000 (17:03 +0200)
commit4e7fdff9ceb906f13129a5b573e3456b1fa95b74
treea0bdc9c6da403f5ff918f07366425d4bb34766e2
parent45a17755a2f62f083b53b7c455df64b69df70291
btrfs: remove ordered extent check and wait during fallocate

For fallocate() 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 a plain fallocate.

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