Re: [RFC ONLY 5/8] btrfs: add code to delete raid extent

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2022/5/17 16:10, Johannes Thumshirn wrote:
> On 17/05/2022 10:06, Qu Wenruo wrote:
>>> +	ret = btrfs_search_slot(trans, stripe_root, &stripe_key, path, -1, 1);
>>> +	if (ret < 0)
>>> +		goto out;
>>> +	if (ret == 0)
>>> +		goto delete;
>>> +
>>> +	leaf = path->nodes[0];
>>> +	slot = path->slots[0];
>>> +	btrfs_item_key_to_cpu(leaf, &found_key, slot);
>>> +	found_start = found_key.objectid;
>>> +	found_end = found_start + found_key.offset;
>>> +
>>> +	/*
>>> +	 * | -- range to drop --|
>>> +	 * | ---------- extent ---------- |
>>> +	 */
>> Thus I believe we don't need those complex checking.
>>
>> The call site has make sure we're the last one owning the file extent,
>> and since raid stripe is 1:1 mapped to the full extent (not just part of
>> a data extent, like btrfs_file_extent_item can do), we should be safe to
>> just do an ASSERT() without the complex split.
>>
>>
>> Thus, I guess to be extra accurate, the 1:1 mapping is between an (data)
>> EXTENT_ITEM and a raid stripe?
>
> Unfortunately not, as we can split extents. I've found out the hard way that
> we need this. See btrfs_drop_extents() for details.

But btrfs extents are immortal, it can only get freed when every bytes
are no longer referred to.

Btrfs_drop_extents() is complex because it's working on file extent
level, but __btrfs_free_extent() is already working on extent level.

Or do you mean, the raid stripe is not really bounded to extent level,
but really bounded to file extent level?

Then I'm not sure if it's a good idea to do such level mapping then.

Thanks,
Qu