Optimal inode size settings

Article Title: optimal inode size setting. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
How big is inode size? Some people say that if there are many small archives, it would be better to use 1024 bytes.
　　
This thinking principle does not seem very cautious. How much is called "more? I think we need a little quantitative analysis.
　　
First, let's "Observe" the influence of inode size on filesystem (fs) and system relativity:
　　
The smaller the inode size, the fatter the inode table, and the smaller the available space.
The smaller the inode size, the longer the link, and the slower the speed.
The smaller the inode size, the higher the space utilization.
In addition, because of the pagesize = 4 K feature of x86, when performing virtual memory operations such as mmap () and swap, if inode size is a multiple of 4 K, it will be more efficient.
　　
Therefore, it seems that inode size <4 K is a disadvantage in addition to a high space utilization.
　　
In general, the improvement of space utilization is not enough to make up for the space wasted by inode table ...... therefore, 4 K is a good experience.
　　
At the last point, we mentioned the fact that the increase in space utilization is not enough to make up for the space wasted due to the hypertrophy of inode tables. It is indeed a fact, unless your fs is designed for BBS systems. The following are some reference data:
　　
Table 1: Relationship between inode size and inode table size
　　 　
So taking a 1 GB partition as an example, different inode size will immediately use the capacity (to save the inode table:
　　
Table 2: inode size and inode table size (in 1 GB fs)
　　 　
Imagine that a 1 GB fs will only use 1024 MB space for inode size = 128, unless we have a lot of small files in the future, it will not be able to be supplemented.
　　
Let's take an example to compare the fs of inode size = 1024 and inode size = 2048:
　　
A file smaller than 1 k exists in fs with inode size = 1024, which saves 1 k space compared to fs with inode size = 2048; however, in the 1 GB fs □, you must have (128.7-64.6) * 1024 = 65614 such small files, and you will be able to earn it ..... is it possible for your fs □to generate so many files smaller than 1 k?
　　
Similarly, for the 512 MB fs □, there will be 32820 files smaller than 1 k to be "earned 』.
　　
A file smaller than 1 k, unless you are using bbs, it is difficult to generate 10000 files in the same file system;
　　
I don't want to give a more practical example. I'm afraid some people do not believe it. The following is my previous statistics on the file size in a 1 GB fs:
　　
Table 3: My statistics on the file size in an old 1 GB fs:
　　 　
OK, it looks obvious that the number of files smaller than 1 k has already accounted for half of the total size. So intuitively think inode size = 1024 is better? Wrong ......
　　
Here is the inode size (fs is 1 GB), which is a waste of space:
　　
Table 4: archive space relative waste size and inode size table:
　　
Therefore, inode size = 4 k is the best.
　　
The calculation of the above "space is relatively a waste of space" is a bit complicated, not to mention. (oh, it's wrong that my algorithm is wrong... So I dare not publish the algorithm)
　　
Inode size = 1024 is the best option to view my bbs situation through the same analysis, because there are more than 40 thousand files smaller than 1 k.
　　
/Usr: inode size = 2048 is the best.