diff options
author | Filipe Manana <fdmanana@suse.com> | 2022-03-15 15:22:40 +0000 |
---|---|---|
committer | David Sterba <dsterba@suse.com> | 2022-05-16 17:03:09 +0200 |
commit | 55961c8abfdcb1f0c8420c5c6bdff86170cf43fc (patch) | |
tree | 00146f6e5d39da7ded923e4909a9f31a6db8c922 /drivers/nvdimm/nd-core.h | |
parent | bd6526d0df0f6be6426118f5f67f24273377a567 (diff) |
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 9902af79c01a8e
("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 e9adabb9712ef9 ("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
8d9b4a162a37ce ("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>
Diffstat (limited to 'drivers/nvdimm/nd-core.h')
0 files changed, 0 insertions, 0 deletions