[TUHS] inodes, inumbers, and versions

[TUHS] inodes, inumbers, and versions

[ron minnich via TUHS]

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

[TUHS] Re: inodes, inumbers, and versions

[Tom Lyon via TUHS]

Sounds like more of a problem with NFS file handles - the server doesn't
keep track of what's open.

On Fri, Feb 6, 2026 at 8:02 AM ron minnich via TUHS <tuhs@tuhs.org> wrote:

> 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
>

[TUHS] Re: inodes, inumbers, and versions

[Bakul Shah via TUHS]

> On Feb 6, 2026, at 8:01 AM, ron minnich via TUHS <tuhs@tuhs.org> wrote:
> 
> 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.

An opened file's dir entry may be removed but its inode would not be removed
until its refcount (number of opens) drops to zero so no such confusion.

> IIRC, there was a version field that was added to the inode (?), so protect
> against this.

This was likely added for the "stateless" NFS to deal with "ABA problem".

[TUHS] Re: 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@tuhs.org>
To "The Eunuchs Hysterical Society" <tuhs@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

[TUHS] Re: inodes, inumbers, and versions

[Larry McVoy via TUHS]

> 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.

That feature was not in the first UFS in BSD nor was it in SunOS.  Want to
nuke your filesystem?  Untar a tarball and pull power while that was running.
Left a huge mess.

ZFS did something about this.

[TUHS] Re: inodes, inumbers, and versions

[Bakul Shah via TUHS]

> On Feb 6, 2026, at 10:14 AM, Ronald Natalie via TUHS <tuhs@tuhs.org> wrote:
> 
> 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 in-core refcount of # of opens (i_count, not i_nlink) protects against
this. Even if you do "rm foo", foo's inode is not freed if someone has foo
open. Its inode is freed only after the last close. [Least how it was in v7).

You do have ensure that the FS structure is consistent after a crash.

[TUHS] Re: inodes, inumbers, and versions

[Clem Cole via TUHS]

below

On Fri, Feb 6, 2026 at 1:14 PM Ronald Natalie via TUHS <tuhs@tuhs.org>
wrote:

> ...
> 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.
>
It was George Goble at Purdue who did the work to "harden" the file system
in the original 4.1BSD code in approx 1980 [which was pushed back to UCB
and was first included in BSD4.1A].  Besides the Dual Vax, George spliced a
PDP-11 into the memory bus of one of his Vaxes and wrote a really neat
memory analyzer/kernel debugger [which, sadly, was before USENIX had formal
papers and may be lost to time].

Using it, he found several races and at least one zero-day issue in 4.1,
all of which led up to his dual-CPU "Purdue Vax," a paper all its own.  I
remember the USENIX meeting (after he found ther zero-day), he had an
invite-only/closed-door meeting with about 10-15 of the major UNIX systems
people, and he explained it and the fix [Unix had a reputation of being
secure, and this was the time of the UNIX *vs.* VMS fights in many places
and George was worried that if the zero-day got out, it would hurt the
reputation of not being "production quality."]   IIRC, the changes for both
file system hardening and this fix were in a Purdue directory on one of the
USENIX tapes [although I may have had them at Tektronix directly from
George].