[TUHS] inodes, inumbers, and versions

[Ronald Natalie via TUHS]

The inode is the essence of the file (pretty much everything other than 
its name).  If it got reused while someone was still referencing it they 
got the wrong file.   The inodes kept  a reffence count of the number of 
directory entries that referred to it so it knew when to deallocate it.  
  There was no “owner” directory, all links to an inode were the same.

After a crash, in the early days, you would run dcheck which would scan 
through all the directories on the system and count references tt and 
then check that against the reference count in the inode.   The most 
common discrepency was that the reference count in both places would go 
to zero but for whatever reason (most likely the file was being held 
open at the crash).   You’d have to manually run clri to mark it unused.

There was a 100 element inode freelist in the superblock, but unlike the 
data block freelist, it wasn’t linked to more free items.   Once the 100 
were used up, the kernel scanned all the inodes looking for freeones to 
repopulate the list.

Eventually, we got fsck, and the systems stopped crashing so much.   
However, it was required to understand the filesystem and the various 
tools:  icheck, dcheck, ncheck, clri, etc...

It wasn’t until later (Berkeley, I think) that someone overhauled the 
filesystem code to assure that things were ordered in a way that never 
left the filesystem in a degenerate state on crashing.

------ Original Message ------
>From "ron minnich via TUHS" <tuhs at tuhs.org>
To "The Eunuchs Hysterical Society" <tuhs at tuhs.org>
Date 2/6/2026 11:01:46 AM
Subject [TUHS] inodes, inumbers, and versions

>At some point there was an issue around inumbers being recycled, such that
>a file might be opened, have an inumber that had been used, and confusion
>followed.
>
>IIRC, there was a version field that was added to the inode (?), so protect
>against this.
>
>I'm sure I've got lots of this wrong. It was a long time ago and the
>neurons are dead.
>
>My question: in our modern era :-), I assume all inumbers are 64 bits, and,
>for a given file system, never reused? Is that a safe assumption?
>
>This has come up as part of a question involving user-mode 9p servers.
>
>thanks