The inode table is a consecutive set of blocks in a filesystem set aside to contain inodes. Each inode in the inode table is 128 bytes long (at least it is in ext2 filesystems: I'm not sure if that changes for other filesystems). These inodes are collections of information about file objects stored in the filesystem. In unix parlance, everything stored in the filesystem is a file object, including directories, documents, and even devices (like a mounted CD, a sound card, et cetera). The information stored in an inode about a file are used by the filesystem to identify the file and its characteristics as needed by the filesystem so that it knows how to handle the file. The information types stored in any inode are an identifying number, the file type, the number of hard links associated with the file, the file's length, file modes, the user and group IDs associated with the file, access rights, and timestamps. I might have missed something.
The actual possible size of the file is determined primarily by the number of bits reserved for the i_size field in the file's inode. The i_size field is 32 bits in ext2 filesystems (I'm pretty sure ext3 and ReiserFS use a system similar to ext2's treatment of 64-bit systems, as discussed below, to get file sizes up to something like 2TB rather than merely 2GB, though I don't know the numbers of the top of my head; I guess I should, since ext3 is what I use the most). If the full 32 bits were used to store the file size, the i_size 32 bit length would make file sizes max out at 4GB, but because the highest-order bit is not used the maximum file size in ext2 on 32-bit architectures is actually 2GB. That's still a pretty big file, though. This limit only applies to 32-bit system architectures.
There's an i_dir_acl field in the inode which is 32 bits in length as well. This field is not used on 32-bit architecture systems, but it is used in 64-bit architecture systems such as Alphas. i_dir_acl serves as an extension of i_size to 64 bits of file size descriptor. An ext2 filesystem can be unmounted from a 64-bit system and mounted on a 32-bit system and will still work, but any files larger than 2GB will not be accessible from within the 32-bit system because the filesystem will not be able to use i_dir_acl. I'm not sure, but I think the reason the highest order bit in i_size isn't used to indicate file sizes is to maintain compatibility with 64-bit systems, and that the purpose of that highest-order bit is to point to i_dir_acl when needed for the file size extension. Since I haven't really dealt with 64-bit architectures much, I'm afraid my understanding of how the two relate is mostly conjecture.
Does that clear some of that up for you?
