• inodes store metadata for every File on your system
  • inodes are fixed size, meaning that their location section is fixed, and therefore they have a max file data size
  • inodes are stored as a list of inodes
    • The Disk location of an inode can be calculated from its inumber, which is an index into the list of inodes
  • They store all the information except the filename and the file data:
    • Size in bytes
    • Location on disk
    • Permissions
      • User, Group, Other
      • Bits go: Read, Write, Execute
      • e.g. -rw-r--r-- means user can read and write, and everyone else can read
    • User id
    • Group id
    • Modification date
    • Reference Count (How many Hard Links lead to this file?)
  • Every file in a given directory is an entry with the filename and inode number. All other information about the file is retrieved from the inode table by referencing the inode number.
  • Inodes numbers are unique at the partition level. Every partition has its own inode table.
  • Every used inode has 1 file. Every file has 1 inode.
  • List inodes with ls -i
  • List inode usage with df -hi
  • See stat <file>
  • Inode tables can get full before the disk space is actually full
  • Inode table size is tied to the disk size, and is created when the Filesystem is created (for EXT)

inumber

inode index number; the index of the inode in the inode Array

Indexed Allocation

This one is basically the UNIX filesystem. The idea is that you store the metadata of the file separately from the data itself. This is implemented using inodes

  • Growth: ❌
    • You can grow files up to the point that you run out of room for disk block address data in your inode, after which you are maxed out for that inode
  • Allocation speed: ✅
  • Space: ✅
    • No external, minimal internal, similar to linked
  • Sequential Access: ✅
    • Same as FAT
  • Random Access: ☑️
    • Same as FAT

Multilevel Indexed Allocation

The basic idea of inodes, but you have the “Location on disk” part of the inode point to index blocks, instead of logical blocks. Index blocks are just blocks that have logical block entries. They could also have index block entries. You can have as many levels of indirection, such that you have a sufficient ability to grow files. The issue is that there is a lot of overhead going on. By having a system that enables you to have really big files, when you use normal size files, you have a bunch of Internal Fragmentation going on.

Hybrid Indexed Allocation

Multilevel Indexed Allocation, but there are multiple indirection levels that all coexist. The bigger the file, the bigger the indirection you use. Fill up the pointers least indirection to most indirection, for this reason. The bigger the file, the slower the access.

  • Growth: ✅
    • The multilevel hybrid model fixes the growth issues associated with the basic indexed allocation
  • Allocation speed: ✅
  • Space: ✅
    • No external, minimal internal, similar to linked
  • Sequential Access: ✅
    • Same as FAT
  • Random Access: ☑️
    • Same as FAT
Link to original