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.
