The only other suggestion would be to track the lowest dnode number that was freed (or better - the lowest dnode in an L2 block that exceeds the fill count threshold, if the fill count is easily accessible). In a huge MDT filesystem (O(1B files) >= 2000 L2 blocks) scanning from the beginning each time might take a non-trivial amount of time, especially if it needs to read any of those blocks from disk. If there is a heavy create+delete workload, then it is likely they will be reusing the same dnodes each time and the rescanning could be kept to a minimum number of blocks.

Again, this could be updated without locking, since "perfect" behaviour would only need to get the minimum within the 512k dnodes of an L2 block, and at worst there would be some L2 block(s) with unused dnodes until some other dnode is unlinked with a lower number or the dataset is next mounted.