What can you do in case the number of blocks becomes greater than the maximal number of files that can be stored in a file system (ext4, FAT, etc.)? In this case (which has actually happened to me), if I sync all blocks, they fill up the whole file system table of the volume.

What is the best way to solve it? Using one directory that is split over multiple volumes? How can you achieve that? Using symlinks or junctions?

There is also a limit of files per directory. This means that the entire copy of the blockchain database should be split over a double amount of directories each time it reaches this threshold (like dynamic hashing).

I tried to search for solutions that address these issues, but I simply couldn't find anything, like nobody has ever thought about these situations.
This is an issue of inodes, a feature mainly in Unix filesystems (like ext4) which is a fixed-size table storing metadata of all files on the partition. When the partition is created, a fixed number of inodes is created.

On my 500GB drive using the default ext4 from Ubuntu, I have 27 million inodes (this can be checked using df -i if you're on Linux), many times more than the number of Bitcoin blocks in the blockchain. Thus I don't run into this issue, and I imagine most people don't - it's possibly something to do with the specific filesystem/setup you're using. 

ext4 specifically doesn't have a cap on the number of files in a directory, so splitting the files into multiple directories would be unlikely to help. FAT32  however has a limit of 65,534 files per directory, the solution there is not to use an outdated filesystem like FAT32.

Generally there are two ways to approach this sort of issue:


Increase the resource (make more inodes)


This can be done by specifying a larger number of inodes when creating the partition, which is relatively easy to do (example) but requires foresight that you're going to be running a node on the partition. Alternatively, make another partition with the required number of inodes.


Use the resource more efficiently (use fewer inodes).


Perhaps the simplest way to achieve this is to just stick multiple blocks in a file - I'm not sure how this would work from an architectural point of view but it's something that would have to be implemented in the client.