On 30.01.20 г. 15:53 ч., David Sterba wrote: > On Mon, Jan 20, 2020 at 04:09:16PM +0200, Nikolay Borisov wrote: >> In preparation to making pinned extents per-transaction ensure that >> log such extents are always excluded from caching. To achieve this in >> addition to marking them via btrfs_pin_extent_for_log_replay they also >> need to be marked with btrfs_add_excluded_extent to prevent log tree >> extent buffer being loaded by the free space caching thread. That's >> required since log treeblocks are not recorded in the extent tree, hence >> they always look free. >> >> Signed-off-by: Nikolay Borisov <nborisov@xxxxxxxx> >> --- >> fs/btrfs/extent-tree.c | 8 ++++++++ >> fs/btrfs/tree-log.c | 2 +- >> 2 files changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c >> index 7dcf9217a622..d680f2ac336b 100644 >> --- a/fs/btrfs/extent-tree.c >> +++ b/fs/btrfs/extent-tree.c >> @@ -2634,6 +2634,8 @@ int btrfs_pin_extent_for_log_replay(struct btrfs_trans_handle *trans, >> struct btrfs_block_group *cache; >> int ret; >> >> + btrfs_add_excluded_extent(trans->fs_info, bytenr, num_bytes); > > Again lack of error handling, I thought that untangling and cleaning up > the extent pinning was motivated to actually handle the errors. Currently btrfs_add_excluded_extent always returns 0. The possible err values from set_extent_bit are not propagated. I think this is a cleanup for another series. > <snip>
