Page 454 - DCAP103_Principle of operating system

Unit 14: Case Study of Linux Operating System

Notes
Figure 14.33: Some Fields in the I-node Structure in Linux

Field Bytes Description

Mode 2 File type, protection bits, setuid, setgid bits
Ninks 2 Number of directory entries pointing to this i-node

Uid 2 UID of the file owner

Gid 2 GID of the file owner

Size 4 File size in bytes

Addr 60 Address of first 12 disk blocks, then 3 indirect blocks

Gen 1 Generation number (incremented every time i-node is reused)
Atime 4 Time the file was last accessed

Mtime 4 Time the file was last modified

Ctime 4 Time the i-node was last changed (except the other times)

Let us consider one possible design—just put a pointer to the i-node in the file descriptor
table. Although simple, unfortunately, this method does not work. The problem is as follows.
Associated with every file descriptor is a file position that tells at which byte the next read (or
write) will start. Where should it go? One possibility is to put it in the i-node table. However,
this approach fails if two or more unrelated processes happen to open the same file at the same
time because each one has its own file position.
A second possibility is to put the file position in the file descriptor table. In this way, every
process that opens a file gets its own private file position. Unfortunately, this scheme fails too,
but the reasoning is more subtle and has to do with the nature of file sharing in Linux. Consider
a shell script, s, consisting of two commands, p1 and p2, to be run in order. If the shell script
is called by the command line

s >x
it is expected that p1 will write its output to x, and then p2 will write its output to x also, starting
at the place where p1 stopped. When the shell forks off p1, x is initially empty, so p1 just starts
writing at file position 0. However, when p1 finishes, some mechanism is needed to make sure
that the initial file position that p2 sees is not 0 (which it would be if the file position were kept
in the file descriptor table), but the value p1 ended with. The way this is achieved is shown in
Figure 14.34. The trick is to introduce a new table, the open file description table between the
file descriptor table and the i-node table, and put the file position (and read/write bit) there.
In this figure, the parent is the shell and the child is first p1 and later p2. When the shell forks
off p1, its user structure (including the file descriptor table) is an exact copy of the shell’s, so
both of them point to the same open file description table entry. When p1 finishes, the shell’s
file descriptor is still pointing to the open file description containing p1’s file position. When
the shell now forks off p2, the new child automatically inherits the file position, without either
it or the shell even having to know what that position is.

LOVELY PROFESSIONAL UNIVERSITY 447