1

The file system defines the block as basic allocation unit. Both the upper and lower limits specified on behalf of operating system. For example, Linux kernel requires the file system block size to be the power of two, but not greater than the virtual memory page size.

What's the motivation behind limiting the file system block size to a virtual memory page size? How this two completely different terms might be related to each other? Is this somehow refers to a mapping mechanism?

mejjete
  • 11
  • 3

3 Answers3

0

The motivation is just simplicity.

Just imagine the bookkeeping that would be required by the operating system if virtual pages sizes were calculated in fractions of file-blocks...

harrymc
  • 480,290
  • Each 4k page in block cache has masks for which 512-byte blocks are valid or dirty. It's not that hard. – stark Feb 01 '23 at 13:46
  • @stark: Not that hard, but why do it when speed is critical. – harrymc Feb 01 '23 at 13:52
  • There is just one virtual page size in an operating system regardless of all used file systems where cluster sizes may vary from one file system to another. The size of a virtual page is typically a fixed one and its choice depends of the hardware support of the processors(s). – r2d3 Feb 01 '23 at 13:54
  • @r2d3: I haven't seen a virtual page size other than 4K in many years, at least on Intel. – harrymc Feb 01 '23 at 13:55
  • @r2d3 most modern architectures support multiple page sizes, at least with hugepages – phuclv Feb 01 '23 at 14:06
0

I always looked at it like this:

If we consider older and limited file systems, block/clustersize had largely to do with the maximum amount of clusters possible/allowed by the file system.

Example, a 12 bit FAT entry puts an upper limit to amount of clusters that can be addressed. 111111111111 is the largest 12-bit binary number. The decimal equivalent of this number would be 4095, and the hexadecimal equivalent would be FFF.

A 16 bit value increases amount of clusters that can be addressed.

So one way of addressing a disk size limitation that is the result of number of clusters we can address is increasing number of bits we can use to address a cluster/block.

Another way however is increasing the cluster or block size.

Increasing number of clusters we can address increases overhead. On the other hand increasing cluster/block size increases waste: Store a 1 KB file inside a 4KB cluster and we waste 3 KB. Or, store a 13 KB file in 4 KB clusters and we again waste 3 KB as we need to allocate 4 clusters to the file.

So, it's a trade-off between overhead and potentially wasted space increase when using large block/cluster sizes. For example, if we know in advance the file system will largely have to deal with large files we can opt for a large cluster size and have the advantage of reduced overhead.

Pages 'act' as 'middle man' between the OS and storage, but pages unlike block/cluster sizes can not be defined by something as file system formatting, rather they're fixed. Efficiency requires common ground between page and block/cluster size and so it's the page size that determines minimum block size as it is a fixed value.

Joep van Steen
  • 6,119
0

The efficient use of cache memory is an argument to prohibit the use of clusters that are smaller than a virtual page.

r2d3
  • 3,554
  • 1
    the limit on Linux is the upper, not lower. With the kernel driver you can mount filesystems with block size smaller than or equal to virtual page size, but not larger – phuclv Feb 01 '23 at 14:08
  • Thank you for letting me know. "but not less than the virtual memory page size." I did not question the statement in the initional posting! – r2d3 Feb 01 '23 at 15:51
  • @phuclv: you are right. I just edited my question. Man page for mke2fs says that: "the kernel is able to mount only file systems with block-size smaller or equal to the system page size - 4k on x86 systems, up to 64k on ppc64 or aarch64 depending on kernel configuration" – mejjete Feb 01 '23 at 16:33