Well obviously the performance is going to be terrible, but it's probably better than the zero performance you get if you block everything while waiting for the system to fully restore from backup.

> what happens when someone runs find on that volume?

It stalls until all the directories are restored? And hopefully pushes those directories to the front of the to-be-restored-from-backup queue, but even without that it's still better than not being able to run any operations on that volume.

It can be worse than zero: your tape drive get hit with lots of small file requests, running much slower than it would be to stream a restore of a large batch containing all of the files you need, and causing increased failure rates on the hardware and media because tape drives are designed to stream, not seek. I’ve had to explain this to multiple HSM admin teams who were trying to save a few bucks on staging HDD capacity and surprised to see it taking over a month to restore a terabyte of data (not joking - and that was with multiple drives!) and hardware failing at like 5x the manufacturer’s estimates.

What you’re trying to do is akin to saying you can write an interface layer to make a railroad look like Uber: at some point the fundamental differences between the architectures are too much to paper over. The situation has improved now that the major operating systems have offline file support so you can make it more obvious that some files are not instantly available but you still need all of your client software to handle that gracefully.