On Monday 02 July 2001 11:12, you wrote:
>
> Link: link can have more than one meaning in the computer world. In
> this context (AFAICT) you want to know about the act of linking several
> parts of a computer program together to make one. (I'm not a C or C++
Right, but I think he was referring to 'link' as in 'ln' rather than 'ld' :)
so I answered with that assumption. In any event, both meanings are answered.
:)
So far, quite a good and thorough explanation overall.
> In Linux (maybe some other operating systems, but not in AFAIK in
> dos/Windows), an inode is a number that refers to a specific storage
> location in a file system (like on a hard disk). Linux directories are
> set up something like this:
>
> There is a place where a filename appears on the disk (like myfile.txt),
> and in that place, there is an inode number (and some other information)
> that indicates where on the disk the contents of myfile.txt is stored.
So far so good. Basically correct, and a directory entry just has a name
followed by an inode. (If you have another directory entry, it can point to
the same inode too -- that is what makes links possible.) There is of course
a bit more information than that stored in the directory entry.
> The equivalent of the place where the filename and inode are stored in
> dos would be known as the fat (file allocation table) -- I'm not sure if
> it's the same in Linux. (And, actually, there is usually more than one
That of course depends on the filesystem -- of course with Linux you have a
dozen or so to choose from, unlke Windows/DOS. Of course, the latter uses a
(variation of) a file allocation table - which when you boil it down is
simply a collection of cluster chains. When DOS or windows opens a file, it
has to look over this fat for a cluster chain that corresponds to the file
and then walks the chain, reading the blocks, until it gets to a cluster with
a special code that signifies the end. This is a relatively simple, but
time-consuming,,operation and much of the time DOS spends is just in trying
to get to the file. That, and other things contribute to the relative
slowness of FAT vs ext2fs.
> inode stored here -- many (most?) files require more than one inode to
> store an entire file, so the inodes for the first several locations are
> stored in the fat. (But not necessarily all inodes.) Really, I'm
Not quite. But that's OK too -- I think you are confusing inodes with blocks.
Big files still only need one inode, but the way the filesystem is set up,
only the first 13 or so blocks (one block = 1K or 4K) of the file can fit in
the inode. (The inode doesn't *contain* the data -- only the pointers to the
data, or block numbers.)
So a really short file might have an inode that contained:
* permission bits ( like rw-r--r--)
* owner info
* block where file is stored (12345, for instance). There's room for about 13
or so block numbers..
If the file is bigger than 13 or so blocks, more space is set aside for
'indirect blocks' - a section of the disk that contains (you guessed it)
pointers to blocks.
> reference on this material. Try searching for some combination of
> inode, Linux, filesystem, and link on Google.)
ext2fs.h in the linux source basically has much of the structure outlined,
but that only helps if you read C well :).
Some of the books I've read show some good diagrams. I can't think of one off
of the top of my head now. And diagrams are really a good way to understand
how all this ties together.
> Randy Kramer
--
------------------------------------------------------------------------
David E. Fox Thanks for letting me
[EMAIL PROTECTED] change magnetic patterns
[EMAIL PROTECTED] on your hard disk.
-----------------------------------------------------------------------
