Background:
In the early days of Linux, the disk size was still MB, and the size of the file system block was only 1 kb to 4 kb. At the time of writing this article, although the TB-level hard disk has recently increased a little price, it does not affect the fact that the hard disk has become too large and the files stored in it are also the same. However, the ext4 file system still manages data in units of 4 kb. The result is that the number of blocks to be managed is too large, and the size of the associated bitmap will inevitably increase, so the overhead of managing these blocks will increase greatly.
Adding the block size of the file system in the kernel will have a profound impact on memory management and page cache. Therefore, it is a terrible task. So everyone is reluctant to touch so many places at once, but this does not prevent file systems from being placed on larger and larger disks. In3.2 KernelMedium,Ext4 can solve this problem
And the http://kernelnewbies.org/Linux_3.2 mentioned: ext4 supports the current block size up to 1 MB, which greatly reduces the time spent doing block allocation and smaller fragments.
What should we do!
Generally, [root @ localhost/] # mkfs. ext4-B 1048576/dev/SDE
Mkfs. ext4: Invalid block size-1048576 (1 m)
Another article mentions:
The "bigalloc" patch introduces a "block cluster" concept to the file system.
Problem:
Is the block size of ext4 replaced by bigallocle?
Progress:
1. centos5.8 cannot upgrade the kernel to 3.2 or above. Upgrading the kernel ....
(Update: Upgrade successful !, I have no examples on the Internet. I can refer to my next article)
2. At present, e2fsporgs still comes with 1.41, which does not reach the 1.42 mentioned on the Internet;
The RPM found depends on the glibc-2.14. After glibc is installed, all the class libraries in the system cannot be loaded and the system crashes! If you have any suggestions, I just want to use the latest features of ext4.