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

[Qu Wenruo <wqu@suse.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2244 bytes --]



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.

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)

Thanks,
Qu

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7027 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]