public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Alright, I give up.  What does the "i" in "inode" stand for?
@ 2002-07-18 22:33 Rob Landley
  2002-07-19  4:38 ` Kelledin
                   ` (5 more replies)
  0 siblings, 6 replies; 43+ messages in thread
From: Rob Landley @ 2002-07-18 22:33 UTC (permalink / raw)
  To: linux-kernel

I've been sitting on this question for years, hoping I'd come across the 
answer, and I STILL don't know what the "i" is short for.  Somebody here has 
got to know this. :)

I know what an inode IS (although it took me almost a year to figure this 
out, way back when), but I don't know what the name means.

I've been following this list for years now, and nobody's ever actually said 
what the i stands for, and neither do the (sparse) comments in fs/inode.c.  
I've read Peter Salus's book "a Quarter Century of Unix".  I've read the 
history of early unix development on Dennis Richie's home page, and although 
it complains that his original notes came back form the dictation service 
misspelling "inode" as "eyenode", it doesn't say what the I stands for.  I'm 
only about a third of the way into "Life with Unix", but it doesn't seem like 
a particularly technical history so far...

Another question I'm unclear about is "does every userspace-visible memory 
allocation have an inode"?  Loaded programs are basically mmaped files, and 
shared memory is now its own filesystem out of which you mmap stuff.  But I 
don't know about a process's stack and heap.

For a while I thought that swap could be thought of as a filesystem out of 
which the heaps were mapped as sparse files (this is the only explanation 
that made sense in early 2.5 when every page used HAD to have swap backing 
store, and taking away the mandatory backing store would just be an exercise 
in deferred allocation), but that apparently is not the case and I got 
disabused of this notion a while back.  Instead I learn what a "classzone" 
is.  Ok...

Then earlier today I wander across kerneltrap's interview with Larry McVoy, 
who espouses the viewpoint that Linux VM design should store statistics in 
inodes rather than worrying so much about individual pages, and I get 
confused again.

Has each process space's heap got an inode?  If so, in what filesystem?

Rob

(Yes, I am breaking the internet convention of posting errors rather than 
asking questions if you want people to respond.  I can come up with some 
errors if you'd like.  I'm good at that. :)

^ permalink raw reply	[flat|nested] 43+ messages in thread
* RE: Alright, I give up.  What does the "i" in "inode" stand for?
@ 2002-07-19  5:08 Mohamed Ghouse , Gurgaon
  0 siblings, 0 replies; 43+ messages in thread
From: Mohamed Ghouse , Gurgaon @ 2002-07-19  5:08 UTC (permalink / raw)
  To: linux-kernel

I think U should have referred 
The Design of the Unix Operating Systems
-Maurice J Bach.

He tells that I stands for Index. ;-)

-MG

-----Original Message-----
From: Rob Landley [mailto:landley@trommello.org]
Sent: Friday, July 19, 2002 4:04 AM
To: linux-kernel@vger.kernel.org
Subject: Alright, I give up. What does the "i" in "inode" stand for?


I've been sitting on this question for years, hoping I'd come across the 
answer, and I STILL don't know what the "i" is short for.  Somebody here has

got to know this. :)

I know what an inode IS (although it took me almost a year to figure this 
out, way back when), but I don't know what the name means.

I've been following this list for years now, and nobody's ever actually said

what the i stands for, and neither do the (sparse) comments in fs/inode.c.  
I've read Peter Salus's book "a Quarter Century of Unix".  I've read the 
history of early unix development on Dennis Richie's home page, and although

it complains that his original notes came back form the dictation service 
misspelling "inode" as "eyenode", it doesn't say what the I stands for.  I'm

only about a third of the way into "Life with Unix", but it doesn't seem
like 
a particularly technical history so far...

Another question I'm unclear about is "does every userspace-visible memory 
allocation have an inode"?  Loaded programs are basically mmaped files, and 
shared memory is now its own filesystem out of which you mmap stuff.  But I 
don't know about a process's stack and heap.

For a while I thought that swap could be thought of as a filesystem out of 
which the heaps were mapped as sparse files (this is the only explanation 
that made sense in early 2.5 when every page used HAD to have swap backing 
store, and taking away the mandatory backing store would just be an exercise

in deferred allocation), but that apparently is not the case and I got 
disabused of this notion a while back.  Instead I learn what a "classzone" 
is.  Ok...

Then earlier today I wander across kerneltrap's interview with Larry McVoy, 
who espouses the viewpoint that Linux VM design should store statistics in 
inodes rather than worrying so much about individual pages, and I get 
confused again.

Has each process space's heap got an inode?  If so, in what filesystem?

Rob

(Yes, I am breaking the internet convention of posting errors rather than 
asking questions if you want people to respond.  I can come up with some 
errors if you'd like.  I'm good at that. :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: Alright, I give up.  What does the "i" in "inode" stand for?
@ 2002-07-19 13:21 Nicholas Berry
  0 siblings, 0 replies; 43+ messages in thread
From: Nicholas Berry @ 2002-07-19 13:21 UTC (permalink / raw)
  To: linux-kernel

>  The pyramid has thirteen levels, symbolising the 
>  thirteen original states. The partially completed state of the
pyramid is 
>  intended to represent the nation under construction. I guess they
crammed 38 
>  more levels in at the very tip.

37.  

38 + 13 = 51. There's only 50 afaik ;).

Nik




^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: Alright, I give up.  What does the "i" in "inode" stand for?
@ 2002-07-19 13:32 Jesse Pollard
  2002-07-30 20:07 ` Mark H. Wood
  0 siblings, 1 reply; 43+ messages in thread
From: Jesse Pollard @ 2002-07-19 13:32 UTC (permalink / raw)
  To: cat, Larry McVoy, Rob Landley, linux-kernel

CaT <cat@zip.com.au>:
> On Thu, Jul 18, 2002 at 09:38:57PM -0700, Larry McVoy wrote:
> > On Thu, Jul 18, 2002 at 06:33:54PM -0400, Rob Landley wrote:
> > > I've been sitting on this question for years, hoping I'd come
> > > across the answer, and I STILL don't know what the "i" is short for.
> > > Somebody here has got to know this. :)
> > 
> > Incore node, I believe.  In the original Unix code there was dinode and
> > inode if I remember correctly, for disk node and incore node.
> 
> That's a new one. I always thought it was 'information node' so in the
> above it'd be disk information node and just information node.
> 
> Makes sense to me in any case. :)

I believe the original description was "index node" since it contains
the contents of the file index - dinode was the disk resident file
index node, which is converted to the memory resident version "inode".

This index node also contains the index references to the disk blocks
allocated to the file.

In even earlier OSs (DEC RSX, TOPS 10) the file index table was actually a file
in the filesystem (usually named index.idx (or was it file.idx...). I don't
know what it was called in MULTICs where the UNIX varient would have
started.

Most of these filesystems were based on contigeuous allocation, or allocations
of contigeous segments. Hence the first file on the system would be a
contigeuous file, containing the references to all files. Since it was
contiguous, the files could be referenced directly by index, without
requiring special handling to retrieve pointers to where the next
segment of the index file - which is still true for most filesystems
under UNIX (the really large ones are moving to tree structures which
require multiple lookups just to find the inode entry...). Directory
structures (at least on the ones I worked with) contained:
	index number, version, name
triples.

Note - the version number had nothing to do with the file version -
it was used to aid file recovery and was only a reuse count of the index
node. The index node contents had to have the same version number as the
directory entry, or the directory entry was considered invalid. The
file name was a rad50, or sixbit (packed) characters, and sometimes was
stored in both inode and directory - again, for rebuilding the file system.

The pointers in the index node were (block, count) pairs
where the count was the number of blocks in the segment, starting at
"block" location. When the list of pointers in the index node were used
up, the last entry would be another (index number, version) pair pointing
to another index node.

This made it fairly fast for I/O since large chunks of the file could be
loaded in one disk access. Faster access could be had by preallocating
the file (useing the copy utility with a "contig" option).

Fragmentation, however, did force a relatively frequent backup/restore cycle
(took all afternoon on the first Saturday of every month for 8 80MB disks).

Sorry - irrestable nostalgia struck....
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

^ permalink raw reply	[flat|nested] 43+ messages in thread
[parent not found: <fa.m2aun2v.khulp2@ifi.uio.no>]
* Re: Alright, I give up. What does the "i" in "inode" stand for?
@ 2002-07-20  2:51 Kevin Puetz
  0 siblings, 0 replies; 43+ messages in thread
From: Kevin Puetz @ 2002-07-20  2:51 UTC (permalink / raw)
  To: landley; +Cc: linux-kernel

> I've been sitting on this question for years, hoping I'd come across the 
> answer, and I STILL don't know what the "i" is short for. Somebody here has 
> got to know this. :) 

The man himself answers... but you probably won't like it :-)
http://www.roesler-ac.de/wolfram/acro/credits.htm#12

The meaning of the i in i-node

From: dmr@plan9.bell-labs.com (Dennis M. Ritchie)
To: wolfram@roesler-ac.de
Date: 06 Apr 2001

I don't remember the discussion, but probably "index".
I can't recall a time when it was expanded out.  The
name was always just i-node.

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: Alright, I give up.  What does the "i" in "inode" stand for?
@ 2002-07-25 13:54 Jesse Pollard
  0 siblings, 0 replies; 43+ messages in thread
From: Jesse Pollard @ 2002-07-25 13:54 UTC (permalink / raw)
  To: imcol, linux-kernel; +Cc: Linux-Kernel Mailing List

Daniel Mose <imcol@unicyclist.com>:
> What bothers my self a bit more in the kernel context, and thus 
> makes me an even more eager "Kernel alienate" than I believe Rob
> to be, are the "atomic_" calls/functions and their semantic origin.
> I believe that every Unix has "atomic_" calls all though perhaps 
> differently designed. And I totally fail to understand why some 
> one decided to name theese functions "atomic_"
> 
> To my own thinking, the atomical parts of any process in a 
> computer are puny little switches that are mostly referred to as 
> bits, and theese bits have all the software support they can get 
> even with out any "atomic_" call. I don't find anything even 
> remotely close to an electron microscope within Unix either.
> So I fail. 

This reference has to do with operations that must be completed
against memory WITHOUT any intervening accesses. The reference "atomic_"
comes from "non-divisible" operations where the operation cannot
or must not be subdivided any further (also from physics where atoms
cannot normally be subdivided).

Most of the time, a single memory reference is considered an atomic
operation. HOWEVER, this fails when you have various sized units. The
data structure is thought of as being composed of multiple elements
of the smallest size (and I'll get to what is considered "smallest size"
later).

First, on a uniprocessor, the processing unit minimum is a byte. Yet many
data elements require 2 or 4 bytes. Using a single instruction to access
the unit would seem to be indivisible... but isn't. Consider the possibility
of a 2 byte data fetch - if one byte is at the end of a memory page, and
the next byte is in the following page, AND that following page is out of
memory... This turns a simple 2 byte fetch (posed here as a single instruction
operation) may turn into several hundred, to several thousand, before that
2 byte sized unit may be fetched. This isn't atomic - meaning indivisible.

The "smallest size" of a system depends on the hardware implementation -
A two byte fetch may be implemented as a single 8 or 16 byte fetch depending
on how the CPU/cache/memory bus/memory are connected. This introduces other
conditions on the definition of "atomic_". If there are two CPUs active then
either, or both, CPUs may access the same data. These access will actually
not occur simultaneously (unless dual ported memory which is truly rare) but
what happens is an interleavling of access. Assuming a bus of 16 bits that
transfers 16 bytes per access - the first CPU would start the activity
transferring 2 bytes. After that transfer, the first CPU starts the next 2
bytes - and the second CPU starts the first 2 bytes. This repeats until all
16 bytes are transferred to both CPUs. This action is not atomic either.

This does not cause problems UNLESS you are updating data. Say removing a
node from a linked list. At this time one CPU may put 2 bytes of pointer back
into the structure (out of 4 bytes), while the second CPU reads the old data,
mixed with the new data. At this point, the operation must be treated more like
a database "transaction", where no access is granted until the transaction is
complete.

The "atomic_" functions implement a method to force all other access to the
data to wait UNTIL the operation (say removing a node from a linked list)
is complete. In many cases, instead of the entire operation being "atomic",
what is implemented is a flag that is "atomic". If the flag is set, wait.
if the flag is clear, set it and continue. NOTE: this is a complex operation
that requires more than on instruction (depending on CPU, instruction set, and
whether there are multiple CPUs). An instruction for this "test and set" can
exist, AND be atomic when used with one CPU. It doesn't necearily mean it is
atomic when used with multiple CPUs. Hence - the functions would implement
a method to support a system wide "atomic" operations that are guaranteed
to be indivisible, even with multiple CPUs in the system.

....
> I realize that most folks In LKML use "foo", "bar" and it's dad,
> "foobar" with outmost joy and that there is complete and utter 
> understanding of what the "foos" and "bars" actually stand for 
> in your contemporary discussion partners reasoning scheeme.

"foo", "bar" and "foobar" (and sometimes "fubar" which I believe is the
origin of the terms) are old slang (see hacker dictionary). They are used
to represent something much more complicated to write...

ie:
	void *foobar()

would mean "a function returning a pointer to a void type" where the actual
NAME of the function is not really relevent to the topic. This can be carried
to connect things like the above together as a form of prototype specification,
used only in describing the prototype, and is not the prototype itself.

No, it isn't 100% accurate. And it is easily misunderstood, especially if
english (the US style) is mixed with the (British syle) and mixed with
non-english transliterations of other idiomatic language structures.

But it means the participants in the discussion LEARN more about communicating
with others - sometimes emotionally, sometimes with laughter, sometimes just
a "oh, so that is what you mean...".

Sometimes it may take a little longer to get to a solution, but it seems to
be more fun, and the result is usually much better than what happens in more
regimented organizations.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

^ permalink raw reply	[flat|nested] 43+ messages in thread
* Re: Alright, I give up.  What does the "i" in "inode" stand for?
@ 2002-07-30 20:58 Jesse Pollard
  0 siblings, 0 replies; 43+ messages in thread
From: Jesse Pollard @ 2002-07-30 20:58 UTC (permalink / raw)
  To: mwood; +Cc: linux-kernel

---------  Received message begins Here  ---------

> 
> On Fri, 19 Jul 2002, Jesse Pollard wrote:
> [snip]
> > In even earlier OSs (DEC RSX, TOPS 10) the file index table was actually a file
> > in the filesystem (usually named index.idx (or was it file.idx...).
> 
> INDEXF.SYS, on TOPS-10.
> 
> >                                                                     I don't
> > know what it was called in MULTICs where the UNIX varient would have
> > started.
> >
> > Most of these filesystems were based on contigeuous allocation, or allocations
> > of contigeous segments.
> 
> "Extents".  "Segments" were contiguous hunks of real memory that the MMU
> knew about, then as now.

I'll accept extents - the "segment" reference was wrong.

> [snip]
> > Note - the version number had nothing to do with the file version -
> > it was used to aid file recovery and was only a reuse count of the index
> > node. The index node contents had to have the same version number as the
> > directory entry, or the directory entry was considered invalid. The
> > file name was a rad50, or sixbit (packed) characters, and sometimes was
> > stored in both inode and directory - again, for rebuilding the file system.
> 
> No, RAD50 and SIXBIT are different.  You can (de)compose SIXBIT words with
> simple shift-and-mask operations, but RAD50 requires arithmetic.  (Hmmm,
> on TOPS-10 we called it RADIX50, so maybe it's different.)

Definitely different. RAD50 was used in FILES-11 and RT-11 disks. It was used
to store 3 characters in a 16 bit word. SIXBIT was used on TOPS-10 36bit
systems to store 6 characters in a word. It also allowed for a fast file
name search since the names were all on word boundaries (full filename
compair took 2 compair, and 1 mask operation 6+3 file names).

> -- 
> Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
> Who just last weekend rediscovered an MF10 core-plane hiding in the filing
> cabinet.

Still got the manuals ? :-)

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

^ permalink raw reply	[flat|nested] 43+ messages in thread

end of thread, other threads:[~2002-08-04 22:25 UTC | newest]

Thread overview: 43+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-07-18 22:33 Alright, I give up. What does the "i" in "inode" stand for? Rob Landley
2002-07-19  4:38 ` Kelledin
2002-07-19  4:38 ` Larry McVoy
2002-07-19  4:45   ` CaT
2002-07-18 23:34     ` Rob Landley
2002-07-19  5:40       ` Thunder from the hill
2002-07-19  0:21         ` Rob Landley
2002-07-19 12:38           ` Kelledin
2002-07-19 13:09           ` Ryan Cumming
2002-07-19  7:00       ` dalecki
2002-07-19 19:58       ` Måns Rullgård
2002-07-19 20:17         ` Cort Dougan
2002-07-20  1:06           ` Kelsey Hudson
2002-07-26 14:15             ` [OT] Why Stallman says GNU/Linux (was Re: Alright, I give up. What does the "i" in "inode" stand for?) Rob Landley
2002-07-19 14:20   ` Alright, I give up. What does the "i" in "inode" stand for? yodaiken
2002-07-20 14:22     ` Georg Nikodym
2002-07-20 14:31       ` yodaiken
2002-07-22 13:10       ` Jesse Pollard
2002-07-20  6:01   ` John Kacur
2002-07-19  4:52 ` Albert D. Cahalan
2002-07-22 22:23 ` Joe DiMartino
2002-07-22 22:49 ` Hiten Pandya
2002-07-25  0:24 ` Daniel Mose
2002-07-25  1:16   ` Andrew Rodland
2002-07-25  2:43   ` jw schultz
2002-07-25  3:18     ` Christian Lavoie
2002-07-25  5:30       ` Ross Vandegrift
2002-07-25 11:08       ` Alan Cox
2002-07-25  6:03   ` Thunder from the hill
2002-07-26  8:24     ` jbradford
2002-07-28  9:01       ` Thunder from the hill
2002-08-04 15:11         ` Gert Menke
2002-07-26 12:54     ` Rob Landley
2002-07-25 18:06   ` Kevin Buhr
2002-07-26 23:39   ` Daniel Mose
  -- strict thread matches above, loose matches on Subject: below --
2002-07-19  5:08 Mohamed Ghouse , Gurgaon
2002-07-19 13:21 Nicholas Berry
2002-07-19 13:32 Jesse Pollard
2002-07-30 20:07 ` Mark H. Wood
     [not found] <fa.m2aun2v.khulp2@ifi.uio.no>
2002-07-20  2:20 ` Kevin Buhr
2002-07-20  2:51 Kevin Puetz
2002-07-25 13:54 Jesse Pollard
2002-07-30 20:58 Jesse Pollard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox