Re: [PATCH 09/11] btrfs: Mark pinned log extents as excluded

Nikolay Borisov
2020-02-05T08:51:19Z

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@suse.com>
>> ---
>> 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>