[NTLUG:Discuss] inodes

[Chris Cox]

Leroy Tennison wrote:
> Another interview question dealt with what inodes contain.  Google is 
> leading to confusion.  I suspect the reason is inadequate qualification 
> of statements but I'd rather find out than be mis-informed.  Statements 
> I'm finding:
> 
> There is no difference between a file and a directory since the latter 
> is just a special type of file. 
> 
> Some references say that inodes describe files 
> (www.cse.psu.edu/~anand/spring01/linux/files.ppt  - slide 2 and 
> http://www.freeos.com/articles/3851/) while one reference 
> (http://www-rohan.sdsu.edu/doc/debian/ch-advanced.html) says that the 
> inode contains the file.
> 
> A hard link is a pointer to an inode.
> 
> A directory is simply a list of filename and inode pairs.
> 
> You can not have a hard link to a directory in most UNIXes.
> 
> Questions:
> 
> If a directory is a file and files are accessed through inodes and users 
> access inodes through hard links then how does a  user access a 
> directory if it doesn't have a hard link in another directory?  Should 
> the statement about most UNIXes not allowing hard links to directories 
> really say that they don't allow more than one hard link to a directory 
> or is there some other answer?

In the early days of Unix, as root, you could make hard links
to directories (an evil thing).  So you could create a scenario
where:

cd /
cd a
cd ..
pwd
d
cd ..
pwd
g
cd ..
pwd
a

and so on... wild stuff.

You could create orphaned directories very easily.

. and .. are the reserved hard links that enable
directory navigation.

If your directory contains lots of sub directories
you'll see a larger link count on the directory
inode because of all of the ..'s in the sub
directories.


> 
> Is the most accurate description of an inode that it contains both 
> information about a file (or directory) such as ownership and 
> permissions as well as  pointers to it's data blocks and, as a result, 
> is the only mechanism for accessing those data blocks as a file?  (I'm 
> excluding the concept of accessing the data blocks as raw storage by 
> lower-level functions doing disk maintenance).

Well ... inodes in Linux are about to get smaller.  It's really
an implementation thing as to what all is contained inside of
an inode.  I don't think you can make a pat answer.

This one is current... but not reflecting what's currently
happening in kernel development...
http://www.cse.unsw.edu.au/~neilb/oss/linux-commentary/vfs-7.html

This one may help too...
http://www.freeos.com/articles/3851/

For more detail, get the book 'Linux Kernel Development,2nd ed',
Robert Love.

It's a Novell publication (you can get it everywhere)... and it's
pretty new still (2.6 kernel).. published in 2005.  See Ch 12,
entitled The Virtual Filesystem.