Re: [PATCH] btrfs: defrag: add under utilized extent to defrag target list

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

On 2024/1/13 02:28, David Sterba wrote:
> On Thu, Jan 11, 2024 at 04:54:47PM +1030, Qu Wenruo wrote:
>>
>>
>> On 2024/1/11 03:39, David Sterba wrote:
>>> On Fri, Jan 05, 2024 at 06:03:40PM +1030, Qu Wenruo wrote:
>>>> [BUG]
>>>> The following script can lead to a very under utilized extent and we
>>>> have no way to use defrag to properly reclaim its wasted space:
>>>>
>>>>     # mkfs.btrfs -f $dev
>>>>     # mount $dev $mnt
>>>>     # xfs_io -f -c "pwrite 0 128M" $mnt/foobar
>>>>     # sync
>>>>     # btrfs filesystem defrag $mnt/foobar
>>>>     # sync
>>>
>>> I don't see what's wrong with this example, as Filipe noted there's a
>>> truncate missing, but still this should be explained better.
>>
>> Sorry, the full explanation looks like this:
>>
>> After above truncation, we will got the following file extent layout:
>>
>> 	item 6 key (257 EXTENT_DATA 0) itemoff 15813 itemsize 53
>> 		generation 7 type 1 (regular)
>> 		extent data disk byte 298844160 nr 134217728
>> 		extent data offset 0 nr 4096 ram 134217728
>> 		extent compression 0 (none)
>>
>> That would be the last 4K referring that 128M extent, aka, wasted
>> (128M-4K) bytes, or 99.695% of the extent.
>
> Ok, so it's the known issue.
>
>> Normally we expect defrag to properly re-dirty the extent so that we can
>> free that 128M extent.
>> But defrag won't touch it at all, mostly due to there is no next extent
>> to merge.
>>
>>> Is this the problem when an overwritten and shared extent is partially
>>> overwritten but still occupying the whole range, aka. bookend extent?
>>> If yes, defrag was never meant to deal with that, though we could use
>>> the interface for that.
>>
>> If we don't go defrag, there is really no good way to do it safely.
>>
>> Sure you can copy the file to another non-btrfs location or dd it.
>> But that's not safe if there is still some process accessing it etc.
>>
>>> As Andrei pointed out, this is more like a garbage collection, get rid
>>> of extent that is partially unreachable. Detecting such extent requires
>>> looking for the unreferenced part of the extent while defragmentation
>>> deals with live data. This could be a new ioctl entirely too. But first
>>> I'd like to know if we're talking about the same thing.
>>
>> Yes, we're talking about the bookend problem.
>> As I would expect defrag to free most, if not all, such bookend extents.
>> (And that's exactly what I recommend to the initial report)
>
> Here the defrag can mean two things, the interface (ioctl and command)
> and the implementation. As defrag tries to merge adjacent extents or
> coalesce small extents and move it to a new location, this may not be
> always necessary just to get rid of the unreachable extent parts.

To me, defrag just means re-dirty the file range.
Whether it would result contig extent or lead to more fragments is not
ensured.
(E.g. defrag a fragmented file, but the fs itself is also super
fragmented, or due to very high memory pressure we have to do writeback
very often).

>
>  From the interface side, we can add a mode that does only the garbage
> collection, effectively just looking up the unreachable parts, trimming
> the extents but leaving the live data intact.

Another thing is, the same bookend problem would lead to very different
behavior, based on whether the file extent has an adjacent extent.

To me, the very basic defrag is just re-dirty all extents, no matter
what (and I believe some older fs is doing exactly that?).

It's us doing extra checks to avoid wasting IO on already very good extents.

>
> The modes of operation:
>
> - current defrag, move if filters and conditons allow that
> - defrag + garbage collect extents
> - just garbage collect extents

Thus I don't really think there is any different between garbage
collection or "defrag".

They are the same thing, just re-dirty the file extents.
(And as stated above, if the result would be better is never ensured).

What we really want to do is, just add extra filters to allow end users
to re-dirty the last file extent.

Thanks,
Qu
>
> The third mode is for use case to let it run on the whole filesystem but
> not try to rewrite everything.
>
> I'm not sure how would it affect send/receive, read-only subvolumes
> should not be touched.
>