• sol6_vi@lemmy.makearmy.io
    link
    fedilink
    arrow-up
    3
    ·
    5 days ago

    I keep seeing things about inodes lately. Can you ELI5 for a novice? Where are the inodes? Are they in the room with us now? 👀

    • oats@piefed.zip
      link
      fedilink
      English
      arrow-up
      4
      ·
      5 days ago

      Extremely simplified:

      Your file system consists of a whole lot of blocks to write data to. Let’s say you have a block size of 512kB, so a 4MB file would span 8 blocks. A 3.7MB file would span 8 blocks, too, as the remaining space can’t get used otherwise.

      Now to get what file exists on which blocks, there’s a large index table, consisting of a number of index nodes (shortened to inode). Each inode saves multiple data fields of a file, like its name, owner, creation data, and the files blocks.

      If you link a file to a second name (hard link) a second inode will get created that points to the same blocks.

      That’s about it. Used to be important to chose the right inode size and count on filesystem creation for the average data you’ll save on the filesystem, as inodes have a fixed count, and the index table takes disk space, too. Too many inodes and you waste space that you could use for precious data, too few inodes and you can’t save new files even when you have free data blocks. With growing disk sizes people just went with massive indexes, who cares about a few wasted megs.

      Modern filesystems (like ext3 and up) introduced journals, which complicate things.