Re: [RFC 0/1] adapting btrfs/237 to work with the new reclaim algorithm

[Pankaj Raghav <p.raghav@samsung.com>]

Hi Johannes,

> Btw, what ever happend to this patch?

As I said before, I had trouble reproducing reclaim for 100G drive size,
and asked if you could reproduce the same on your end. I did not get any
reply to that.

I wanted to discuss with you what I was seeing during ALPSS, but we never
got around that!

Regards,
Pankaj

On 2022-08-23 13:46, Pankaj Raghav wrote:
> On 2022-08-22 16:29, Johannes Thumshirn wrote:
>>>
>>> Only partial reclaim is happening for bigger sized drives. The issue
>>> with that is, if I do another FIO transfer, the drive spits out ENOSPC
>>> before its actual capacity is reached as most of the zones have not been
>>> reclaimed back and are basically in an unusable state.
>>>
>>> Is there a limit on how many bgs can be reclaimed?
>>>
>>> Let me know if I am doing something wrong in the test or if it is an
>>> actual issue.
>>
>> Can you try setting max_active_zones to 0? I have the feeling it's yet 
>> another (or perhaps already known, Naohiro shoudl know that) issue with 
>> MAZ handling.
> 
> The Max active zones is set to 0 (QEMU defaults to 0). I also changed the
> backing image format of QEMU from qcow to raw, and still the same issue of
> partial reclaim for a drive size of 100G.
> 
> I tried the same test in a 100G drive with 1G zone size, and it is working
> as expected.
> 
> root@zns-btrfs-simple-zns:/data# ./reclaim_script.sh
> Open zones before big file transfer:
> 4
> Open zones before removing the file:
> 59
> Going to sleep. Removed the file
> Open zones after reclaim:
> 4
> 
> I am not 100% sure what is causing this issue of partial reclaim when the
> number of zones is higher.