[TUHS] inode - does it have a meaning?

steve jenkin via TUHS tuhs at tuhs.org
Sun Oct 5 07:57:15 AEST 2025


In 1989, Ken was interviewed by Mike Mahoney of Princeton, as part of the “Unix Oral History Project”.

It seems ‘inode’ was being used from 1969 when Ken & Dennis were doing design, with Rudd Canaday in his office.

======================

Princeton have removed the original site.

Copes can be found at:
	<https://dspinellis.github.io/oral-history-of-unix/Mahoney/unixhistory.htm>
	<https://mirror.math.princeton.edu/pub/unixarchive/Documentation/OralHistory/>

An edited summary by Mahoney:
	<https://mirror.math.princeton.edu/pub/unixarchive/Documentation/OralHistory/expotape.htm>

======================

Ken’s Interview of "9-6-89"
	<https://dspinellis.github.io/oral-history-of-unix/mike/transcripts/thompson.htm>

Thompson: Yeah. I was doing it on the 635 at the time. Yeah . 
I got these exponential curves where before it would get into trouble it would go way out and get lots and lots of simultaneous accesses going… 
I was playing with a disk sorting algorithms and caching algorithms at the time. 
All of those actually went into UNIX. Um.

MSM: This would be the research aspect of the work?

Thompson: Yeah. Then in the actual design. 
At that point, it just went to… 
There was a model of a user and a model of this, and they generated activities, 
and the activity went into the disks that were sorted and things like that. Um, um. 
It was never down to a design to the point of where you put the addresses, how you expand files and things like that. 
It was never down to that level. 
It was always at some higher level. 

I think it was just like one or two meetings, Dennis and Canaday and myself. 

Was just discussing these ideas of the general nature of keeping the files out of each other's hair and the nitty-gritty of expanding. 

Of the real implementation, where you put the block addresses, where you put this and this. 
I remember, um, we did it in Canaday's office. 
At the end of this discussion Canaday picked up the phone, 
	and there was a new service in Bell Laboratories, dictation, 
	where you call up essentially a tape recorder and you give notes,
	and then the next morning notes are typed and sent to you. 

The next day, these notes came back and the acronyms were butchered, like "inode" was "eyen" (Laughing).

======================

> On 5 Oct 2025, at 07:38, David Barto via TUHS <tuhs at tuhs.org> wrote:
> 
> In a blog post today I read:
> 
> 	In most modern file systems, those data structures are
> 	known as inodes, and their numbers are inode numbers,
> 	sometimes shortened to inodes. The term is thought
> 	to be a contraction of index node, which certainly
> 	makes sense, but is lost in the mists of time.
> 
> This was written by a fellow who is reasonably smart and knows
> his way around things MacOS, though not things UNIX. So before
> I go and tell him that inode really does mean ‘index node’, I’m
> checking here to clear the “mists of time.”
> 
> I’ve always understood it to be a shortening of ‘index node’.
> 
> Wikipedia (https://en.wikipedia.org/wiki/Inode) says
> 
> 	There has been uncertainty on the Linux kernel mailing list
> 	about the reason for the "i" in "inode". In 2002, the question
> 	was brought to Unix pioneer Dennis Ritchie, who replied:[4]
> 	
> 	In truth, I don't know either. It was just a term that we
> 	started to use. "Index" is my best guess, because of the
> 	slightly unusual file system structure that stored the
> 	access information of files as a flat array on the disk,
> 	with all the hierarchical directory information living
> 	aside from this. Thus the i-number is an index in this array,
> 	the i-node is the selected element of the array.
> 	(The "i-" notation was used in the 1st edition manual;
> 	its hyphen was gradually dropped.)
> 
> Further the Wikipedia article states that Bach says that the word ‘inode’
> is a contraction of the term index node.
> 
> So is there a ‘definitive’ answer for this, or is it really lost in
> the mists of time?
> 
> 	David
> 
> Men always learn from their mistakes how to make new ones.
> A.J.P. Taylor
> 
> David Barto
> barto at kdbarto.org
> 
> 
> 

--
Steve Jenkin, IT Systems and Design 
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA

mailto:sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin



More information about the TUHS mailing list