My apologies, I seem to have lost track of this thread. My "solution" was to just stop writing to flash, but the underlying issue never got resolved. I can also add that a reboot does not free up any of the unused space. Please see the thread below because a reboot may, in part, be causing the issue.

>>>What is happening is that there is very little free space in the system and these blocks are "churning".

I'm not sure I understand how the garbage collector works. If there is a block to be free'd ("GC Selected block 3437 with 1 free, prioritised:0"), wouldn't that block go away for a bit at least? The same handfull of blocks are rapidly being free'd, even though I've stopped writing to the flash.

On the afflicted systems, I deleted some files to make some usable space, and that little space behaved as expected (i.e. I could write and delete files). I could see the "churning" if there was nearly zero free space and data was still being written, but neither of these seem to be the case at this point. It seems like that handful of blocks are not successfully free'd.

My speculation is still that the blocks are not being successfully free'd and that the GC is picking the same few blocks to free (I could very well be wrong on that).

Here is a relevant thread regarding this issue.
https://dev.openwrt.org/ticket/16651

Is there any utility for defragmenting the YAFFS filesystem?

Is there a way to forcibly mark some block numbers bad from userland? It would be interesting to mark that handful of blocks bad and see if the GC moves on, or continues to churn.

Thanks.