2

File systems all have varying limits, why is this case in a very technical standpoint? So really, what allows one file system to have a greater file size or a greater partition size then another file system?

One of my theories was seeded from the use of inodes and how file systems create a set amount of inodes when the partition is formatted; however, this only explains the max amount of files in a file system.

Improve this question
3
  • 2
    Flagging for closure as too broad, each file system has it's limits for varying reasons... Some technical, some arbitrary, and some due to available hardware at the time it was developed. Also, a quick Google search would likely answer this question for common file systems.
    – acejavelin
    Nov 23, 2017 at 13:52
  • Inodes are a Unix thing, not all filesystems have them or need them. E.g. NTFS uses a Master File Table instead. ($MFT)
    – MSalters
    Nov 23, 2017 at 14:12
  • 1
    Op, if you start studying the boundary between hardware and software, and the low level software designed to support it, you will see many similar rules and limitations. there are hundreds or thousands of points where the practical realities of hardware or software design required practical limitations. for instance, why is a byte 8 bits on intel systems? why is a word 32 bits on a 32bit system? or even more basic, why is everything in powers of two? Computers are made from these decisions, and without them, none of it can fit together.
    – Frank Thomas
    Nov 23, 2017 at 19:38

1 Answer 1

Reset to default
4

Many such limits come from data structures containing fixed-size fields where a count (of bytes, sectors, etc.) would be stored.

For example, the MBR partition table (the way modern operating systems use it) has 32-bit fields for sector count. That's four bytes, a "convenient" size for CPUs. (The more recent GPT partitioning format uses 64-bit values.)

The biggest number that could possibly fit in 32 binary digits is 232-1, or 4294967295 in decimal. For disks with 512-byte sectors, that means 2199023255040 bytes – just a sector short of 2 TiB.

You can find similar issues everywhere – the FAT32 file system can only have up to 232-1 clusters (although a cluster in FAT can vary in size; that's the "allocation unit" you see when formatting) and hold files up to 232-1 bytes (4 GiB) because of the same field size limit.

At the time when various filesystems were created, their maximum limit most likely seemed utterly ridiculous and "unlikely to be an issue", and it would have been quite inefficient to work with 64-bit or possibly even 32-bit numbers in a system running MS-DOS. (The early MS-DOS versions didn't even support folders!)

Nowadays filesystems use 64-bit counts, which is again "unlikely to be an issue" (264 is a lot).

But besides that, modern file systems have changed a lot. Instead of static inode tables or linear directory entries, they now grow as needed, and use structures such as B+trees. (I'm talking about NTFS, ZFS, possibly XFS...)

Improve this answer
2
  • these same concepts extend into higher layer structures as well. FAT was designed with a name table that allowed a maximum of 255 8.3 file names per directory, and later when long filename support came along, they just chained multiple names together to store longer ones, but the max name characters per directory remained 255 * (8 + 3) .
    – Frank Thomas
    Nov 23, 2017 at 19:32
  • Also, the complexity that comes with what "modern file systems" do tends to come at a slight cost - which might be insignificant today but wouldn't have been insignificant at all in MS DOS days, and even today might not be insignificant in smaller embedded systems (especially "void main()" type environments)
    – rackandboneman
    Mar 27, 2018 at 20:26

Not the answer you're looking for? Browse other questions tagged or ask your own question.