Calculate the number of disk blocks required to store a file given the filesystem block size.
Filesystems allocate space in fixed-size blocks, so any file not landing on an exact multiple of the block size wastes the remainder of its final block — this unused space is called slack. A workload dominated by many small files (session data, cache entries, thumbnails) suffers proportionally more slack waste with a large block size, since a 3KB file on a 4KB filesystem wastes 1KB (25%) per file, while the same file on an 8KB filesystem wastes 5KB (62.5%). Conversely, very large files see negligible slack waste regardless of block size, since the wasted final partial block is a tiny fraction of the total file size — but larger block sizes reduce the metadata (block-mapping) overhead per file, which matters more for large-file workloads.
Blocks required per file
blocks_per_file = ceil(avg_file_size / block_size)
Waste percentage
waste% = (block_size − avg_file_size mod block_size) / block_size × 100
4KB matches the standard memory page size on most systems, which lets the kernel map file pages into memory efficiently without extra translation overhead, and represents a reasonable middle ground between metadata overhead for large files and slack waste for small ones on typical mixed workloads.
A smaller block size helps when the filesystem will overwhelmingly store many small files (well under 4KB each), such as certain mail spool or cache directory layouts, where minimizing per-file slack matters more than the slightly higher metadata overhead of tracking more blocks per large file.
No — block size is fixed at filesystem creation time (mkfs) for ext4, xfs and most traditional Linux filesystems; changing it requires backing up data, reformatting with the new block size, and restoring, so it should be planned for upfront based on the expected workload.