I read that file systems usually access data in blocks, whose size is integral multiple of disk block size. Why don’t they read individual disk blocks?
1
Because reading multiple blocks allows the OS to cache the next few blocks and avoid the latency when the application eventually needs them.
The biggest slowdown in accessing spinning disk drives (HDD and optical disk) is the seek time, literally the reading head moving to where the track with the block is.
This is alleviated with solid state but reading adjacent blocks is still faster than reading out of order.
Read speed and caching is an important factor, but it’s not the only factor, and perhaps not even the primary factor in selecting a filesystem’s block size. Every block on your filesystem has overhead associated with it. The filesystem must track which blocks are free, which blocks belong to which files, etc. This overhead must be stored on the disk somewhere, which takes away useful space that actually stores data.
If you make your filesystem blocks larger, that makes your overhead smaller, and gives you more useful space. The trade off is the risk of more slack space in the last block of a file, which takes away useful space. Some filesystems mitigate this risk by using a variable block size, or by block suballocation. That comes with its own overhead and tradeoffs. Also, blocks that are too large may no longer fit into a CPU’s cache.
Then the question becomes why don’t disk manufacturers just make their block sizes larger to better match the filesystem block sizes? Two main reasons. One is that disk manufacturers don’t know what kind of filesystem will eventually be put on there. The ideal block size for a desktop with a lot of little files is different from a media server in a RAID configuration storing movies, for example. The second reason is manufacturing defects and wear might cause blocks to be marked as unusable, so it’s important to select disk block sizes that will maximize the amount of useful remaining space when a defect occurs.