On Fri, Jan 12, 2001 at 02:49:09AM -0500, Statux wrote:
> inodes aren't used with every filesystem. MSDOS, for instance, uses
> "allocation units" for header info and data.
>
> I forget what the "i" in inode stands for but I've always known it to be
> "index."
Close...information node.
You have to think back to when Unix was being...well, designed is OK,
but escaping is more like it. At that time, the only micro OS was CP/M;
everything else was mainframe or its cultural equivalent on minicomputers.
Hierarchical disk directories were understood and implemented, thanks to
Multics, but partitioned data sets still ruled on Big Iron.
In almost all cases, disk directories were nasty, complicated critters
that held all information about a file. There were a lot of complications
to use and maintenance--more than I want to go into this early with
no coffee. One example is that directory space was a critical system
resource--you could get in the position of not being able to create new
files, and expanding the directory on a disk was an administrative effort.
This, and other issues, were annoying. Enough so that the Boyz at Bell
looked at how to change this in Unix.
In any case, the resultant Unix model was a novel departure from this
model. Instead of a long, complex directory entry that held all the
information about a file, they moved all this to a chunk called the
i-node. The directory entry became nothing more than a slot in a mildly
special file that had a pointer to the associated i-node and a filename.
In fact, back then you could just "od -c" the directory and _see_ the
i-node/filename pairs. (Today, it's a bit more complex; being sequential
files, directory searches could get expensive in large directories
and busy systems, so most *nixen today do some sort of directory hash,
first seen on BSD systems.)
The i-node, then, was a chunk of data that actually described the file--
owner, attributes, creation/modification times, etc. It also contained
the pointers to the first few real blocks and one to the first 'indirect'
block (a block that contains pointers to other blocks...and there were
triple indirect blocks...this allowed then-unheard-of filesizes).
This gave the system a lot of flexibility not common before this. I-nodes
could be reallocated, moved, the pool expanded--all without having to
shuffle and reorganize the whole disk. (In practice, this wasn't often
seamlessly implemented--the AT&T systems didn't have utilities to grow
i-node lists, for instance--but I've seen programs that did some pretty
extensive shuffling and reorganizing of the filesystem.) Corruption of
a directory was annoying, but not catastrophic. Corruption of one or
more i-nodes just damaged the files related to them; not the whole disk.
And so on.
The entire concept of links arose from the fact that the directory entry
was now just a way of providing a mnemonic for the file--you could have
multiple directory entries point to the same i-node. Some scoffed,
but we all know how useful this turned out to be.
I-nodes also allowed for the Unix model in which devices are files, too--
just have special entries in the i-node that indicates to the system it
represents a "special file", and requests should be handed off to the
driver associated with that file type.
Enough for now. I'm sure others will jump in to correct my nits and add
more.
Cheers,
--
Dave Ihnat
[EMAIL PROTECTED]
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
