22

Unix file systems usually have an inode table, and the number of entries in this table is usually fixed at the time the file system is created. This sometimes leads to people with plenty of disk space getting confusing error messages about no free space, and even after they figure out what the problem is, there is no easy solution for what to do about it.

But it seems (to me) that it would be very desirable to avoid this whole mess by allocating inodes on demand, completely transparently to users and system administrators. If you're into cute hacks, you could even make the inode table itself be a file, and thus reuse the code you already have that finds free space on the disk. If you're lucky, you might even end up with the inodes near the files themselves, without explicitly trying to achieve this result.

But nobody (that I know of) actually does this, so there's probably a catch that I'm missing. Any idea what it might be?

Improve this question
2
  • 4
    You have just reinvented the Master File Directory and Index of Files-11 in VMS, the precursor of the Master File Table in NTFS.
    – JdeBP
    Apr 6, 2018 at 8:01
  • 1
    I reinvented the precursor to the MFT? Cool!
    – Mark VY
    Apr 6, 2018 at 17:13

3 Answers 3

Reset to default
27

Say you did make the inode table a file; then the next question is... where do you store information about that file? You'd thus need "real" inodes and "extended" inodes, like an MS-DOS partition table. Given, you'd only need one (or maybe a few — e.g., to also have your journal be a file). But you'd actually have special cases, different code. Any corruption to that file would be disastrous, too. And consider that, before journaling, it was common for files that were being written e.g., when the power went out to be heavily damaged. Your file operations would have to be a lot more robust vs. power failure/crash/etc. than they were on, e.g., ext2.

Traditional Unix filesystems found a simpler (and more robust) solution: put an inode block (or group of blocks) every X blocks. Then you find them by simple arithmetic. Of course, then it's not possible to add more (without restructuring the entire filesystem). And even if you lose/corrupt the inode block you were writing to when the power failed, that's only losing a few inodes — far better than a substantial portion of the filesystem.

More modern designs use things like B-tree variants. Modern filesystems like btrfs, XFS, and ZFS do not suffer from inode limits.

Improve this answer
6
  • 2
    When you say "do not suffer from inode limits", does that mean new inodes are allocated completely behind-the-scenes, or does someone need to run a command like "expand-table-now-please"?
    – Mark VY
    Apr 5, 2018 at 23:03
  • 3
    @MarkVY completely behind the scenes (if inodes are really used at all).
    – derobert
    Apr 5, 2018 at 23:07
  • Okay, so my knowledge is just way behind the times apparently. Thank you for the detailed answer. I never thought about what would happen in the case of power loss or similar. So my cute hack is pretty dangerous unless "append to file" is already an atomic operation in the file system. Which you claim was pretty rare back in the olden days.
    – Mark VY
    Apr 5, 2018 at 23:11
  • I remember XFS and btrfs very occasionally suffering from mild filesystem corruption -- zfs too? It's not a risk for some, but it could be a risk for important data, and the cost of the dynamic allocation. For XFS at this shop, its deal-breaking issue was a complete inability to shrink a filesystem via any means.
    – user2066657
    Apr 6, 2018 at 16:34
  • Btrfs may not suffer from inode limits, but it suffers from a completely different fault that causes similarly confusing symptoms (basically, it runs out of metadata space while still having plenty of data space available, due to inefficient use of block groups). This not only causes it to report disk-full errors when df reports plenty of space available, it can't be fixed by deleting files because deleting a file requires allocating metadata space.
    – Mark
    Apr 6, 2018 at 20:22
19

Many filesystems do have a dynamically allocatable inode table (or its moral equivalent) (XFS, BTRFS, ZFS, VxFS...)

The original Unix UFS though had inodes that were fixed at filesystem creation time and filesystems derived from it (Linux EXT, Solaris UFS) often continued the scheme. It's robust and simpler to implement. So many use cases are a good fit, that designing a new filesystem just to avoid that one problem isn't easy to justify.

Improve this answer
2
  • 1
    So much progress in computing has been made by people solving not-easy-to-justify-solving problems, though.
    – user253751
    Apr 6, 2018 at 3:46
  • 2
    But also, much progress in not-easy-to-solve-solutions :) Early "complex" file systems - NT era NTFS, reiserfs - had a way of failing catastrophically WHEN they failed....
    – rackandboneman
    Apr 6, 2018 at 15:45
6

There are filesystems that allocate inodes dynamically: off the top of my head, at least Veritas VxFS (= the default filesystem of HP-UX, and one of the choices available on Solaris) and XFS (the standard filesystem type on RHEL 7) work that way. Btrfs and IBM's JFS too.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .