• describes a filesystem object
  • what’s in an inode?
    • mode
    • owners (user, group)
    • timestamps (creation, modification, access time)
    • block size count (how many blocks does this file consume)
    • actual blocks, organised contiguously in memory as pointers
      • usually first 12 blocks of file
      • if smaller, it won’t use blocks to store ptr
      • if bigger, we have indirect pointers
    • single indirect == to another block which stores pointers
    • doubly indirect == to another block of singly indirect pointers
    • triply indirect == to another block of doubly indirect pointer
  • why multiple indirections?
    • efficient for small files, but still be able to support large ones
    • total 60 bytes for 4 byte ptrs each
    • if small enough, could just store inside inode itself
  • directory entry (filename) is a hard link
    • one hard link points to one inode

ln <SRC> <DEST>

  • creates a new hard link pointing to source.
  • destination is name of new link, now both point to same inode

rm only removes inode link in recycling bin, creates hard link to inode. after timeout or bin cleared, it clears the link and deletes the file

  • softlinks/symlink: name to a name
    • b.txt is its own inode, but it just points to another file name
    • if pointer can’t be resolved, weird error (exception)

inode stores a lot of things:

  • doesn’t know filename, containing directory name
  • knows file size and type
  • doesn’t know number of soft links, location of soft links
  • knows number of hard links, not locations of hard links
  • stat : 4096 / 8 == 512 sized blocks idk
  • access rights, timestamps, stored in inode
  • pointers to file contents (unless too small)
  • ordered list of data blocks (pointers to data blocks)