summaryrefslogtreecommitdiffstats
path: root/fs/btrfs/tree-checker.c
diff options
context:
space:
mode:
authorFilipe Manana <fdmanana@suse.com>2022-03-15 16:22:41 +0100
committerDavid Sterba <dsterba@suse.com>2022-05-16 17:03:09 +0200
commit63c34cb4c6dddd7899a14ed0a11b208a41e9c85c (patch)
treec39dddcc55bce02fd51bc05b68020557e19c3f95 /fs/btrfs/tree-checker.c
parentbtrfs: remove ordered extent check and wait during hole punching and zero range (diff)
downloadlinux-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