diff options
author | Filipe Manana <fdmanana@suse.com> | 2022-03-15 16:22:41 +0100 |
---|---|---|
committer | David Sterba <dsterba@suse.com> | 2022-05-16 17:03:09 +0200 |
commit | 63c34cb4c6dddd7899a14ed0a11b208a41e9c85c (patch) | |
tree | c39dddcc55bce02fd51bc05b68020557e19c3f95 /fs/btrfs/tree-checker.c | |
parent | btrfs: remove ordered extent check and wait during hole punching and zero range (diff) | |
download | linux-63c34cb4c6dddd7899a14ed0a11b208a41e9c85c.tar.xz linux-63c34cb4c6dddd7899a14ed0a11b208a41e9c85c.zip |
btrfs: add and use helper to assert an inode range is clean
We have four different scenarios where we don't expect to find ordered
extents after locking a file range:
1) During plain fallocate;
2) During hole punching;
3) During zero range;
4) During reflinks (both cloning and deduplication).
This is because in all these cases we follow the pattern:
1) Lock the inode's VFS lock in exclusive mode;
2) Lock the inode's i_mmap_lock in exclusive node, to serialize with
mmap writes;
3) Flush delalloc in a file range and wait for all ordered extents
to complete - both done through btrfs_wait_ordered_range();
4) Lock the file range in the inode's io_tree.
So add a helper that asserts that we don't have ordered extents for a
given range. Make the four scenarios listed above use this helper after
locking the respective file range.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'fs/btrfs/tree-checker.c')
0 files changed, 0 insertions, 0 deletions