inode

Re: inode table

---

• From : "Enrique Perez-Terron" <enrio@xxxxxxxxx >
• Date : Sun, 08 Jan 2006 14:18:23 +0100

---

On Sat, 07 Jan 2006 09:13:25 +0100, x <cupidisdangerous@xxxxxxxxxxx> wrote:

 

hi

I was wondering if there is anyway of seeing or accessing the inode

table. If yes then can i make some changes to this table. If yes then

how and what changes can be made to this table.

I was told by somebody that my question is the same as if i am asking

to touch FAT or FAT32. In my opinion it would have been the case if had

asked to access ext3.

Plz be elaborate in your reply as i am new to your comunity

Thanx in advance

Bye and Take care.

Inodes contain information about a file, such as the size, the date of

last modification, or who is the owner.  Most of this information can be

changed, there are commands to change the access permissions (chmod),

the owhership (chown), and even the modification timestamp (touch).

 

This information is stored in the file system. However, different

file systems organize the information in different ways, and

the ext2 and ext3 file systems have a way of doing this too.

(These two fs types do it the same way; the difference between

ext2 and ext3 is that ext3 has a journal, all else is the same.)

 

In other words, to access the inode table in a file system of type

ext3 *is* to access the ext3 data structures.

 

The kernel also keeps a copy  of some indoes in its memory, as long

as the corresponding file is being accessed. This copy has a different

layout of the information than the on-disk copy, and I believe the

in-kernel layout is independent of the file system type.

 

The inodes also contain information about where the file's data is

stored, that is, which blocks do you need to access, to access the

actual contents of the file.  If you change this information without

doing a number of other, corresponding changes, you will bring the

file system into an inconsistent state.  You will, for example

get an inode that points to blocks that belong to other files, or

points to blocks that are also marked as free, available for new files.

(I don't know if ext3 uses a list or a bitmap to keep track of free

space.)

 

There are no regular commands I know of, that give a straight

table view of the collection of inodes.   All unix or linux system

calls access the inodes indirectly, by file name, or by open-file

handle, which in turn has to be obtained using a file name.

 

There are of course programs that access a disk partition bypassing

the file-system code, reading and writing the blocks of the partition

by block numbers. Such programs can be used to fix problems, or to

debug or simply explore. Programs like fsck (file system check and

repair), badblocks, or debugfs do this. The latter has also commands

to dump the contents of an inode to the screen.

 

-Enrique



======================================================================================

vfs的supper bolck、inode、dentry和file关系简述

The common file model consists of the following object types: <1> The superblock object Stores information concerning a mounted filesystem. For disk-based filesystems, this object usually corresponds to a filesystem control block stored on disk. <2> The inode object Stores general information about a specific file. For disk-based filesystems, this object usually corresponds to a file control block stored on disk. Each inode object is associated with an inode number, which uniquely identifies the file within the filesystem. <3> The file object Stores information about the interaction between an open file and a process. This information exists only in kernel memory during the period when a process has the file open. <4> The dentry object Stores information about the linking of a directory entry (that is, a particular name of the file) with the corresponding file. Each disk-based filesystem stores this information in its own particular way on disk. Figure 12-2 illustrates with a simple example how processes interact with files. Three different processes have opened the same file, two of them using the same hard link. In this case, each of the three processes uses its own file object, while only two dentry objects are requiredone for each hard link. Both dentry objects refer to the same inode object, which identifies the superblock object and, together with the latter, the common disk file. Figure 12-2. Interaction between processes and VFS objects