|
|
|
Modern Operating Systems by Herbert Bos and Andrew S. Tanenb...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf
Showing 818-819 out of 1137
Modern Operating Systems by Herbert Bos and Andrew...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Modern Operating Systems by Herbert...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf-M ODERN O PERATING S YSTEMS
Page 818
SEC. 10.6
THE LINUX FILE SYSTEM
787
19
(a)
42
F
8
F 10
88
D
6
bigdir
colossal
voluminous
Unused
19
(b)
F
8
88
D
6
bigdir
colossal
Unused
Unused
I-node number
Entry size
Type
File name length
Figure 10-32.
(a) A Linux directory with three files. (b) The same directory af-
ter the file
voluminous
has been removed.
name is padded by an unknown length. That is the meaning of the arrow in
Fig. 10-32.
Then comes the type field: file, directory, and so on. The last fixed
field is the length of the actual file name in bytes, 8, 10, and 6 in this example.
Finally, comes the file name itself, terminated by a 0 byte and padded out to a
32-bit boundary. Additional padding may follow that.
In Fig. 10-32(b) we see the same directory after the entry for
voluminous
has
been removed. All the removeal has done is increase the size of the total entry field
for
colossal
, turning the former field for
voluminous
into padding for the first entry.
This padding can be used for a subsequent entry, of course.
Since directories are searched linearly, it can take a long time to find an entry
at the end of a large directory. Therefore, the system maintains a cache of recently
accessed directories. This cache is searched using the name of the file, and if a hit
occurs, the costly linear search is avoided. A
dentry
object is entered in the dentry
cache for each of the path components, and, through its i-node, the directory is
searched for the subsequent path element entry, until the actual file i-node is
reached.
For instance, to look up a file specified with an absolute path name, such as
/usr/ast/file
, the following steps are required. First, the system locates the root di-
rectory, which generally uses i-node 2, especially when i-node 1 is reserved for
bad-block handling.
It places an entry in the dentry cache for future lookups of the
root directory.
Then it looks up the string ‘‘usr’’ in the root directory, to get the i-
node number of the
/usr
directory, which is also entered in the dentry cache. This i-
node is then fetched, and the disk blocks are extracted from it, so the
/usr
directory
can be read and searched for the string ‘‘ast’’. Once this entry is found, the i-node
Page 819
788
CASE STUDY 1: UNIX, LINUX, AND ANDROID
CHAP. 10
number for the
/usr/ast
directory can be taken from it. Armed with the i-node num-
ber of the
/usr/ast
directory, this i-node can be read and the directory blocks locat-
ed. Finally, ‘‘file’’ is looked up and its i-node number found.
Thus, the use of a rel-
ative path name is not only more convenient for the user, but it also saves a sub-
stantial amount of work for the system.
If the file is present, the system extracts the i-node number and uses it as an
index into the i-node table (on disk) to locate the corresponding i-node and bring it
into memory. The i-node is put in the
i-node table
, a kernel data structure that
holds all the i-nodes for currently open files and directories. The format of the i-
node entries, as a bare minimum, must contain all the fields returned by the
stat
system call so as to make
stat
work (see Fig. 10-28). In Fig. 10-33 we show some
of the fields included in the i-node structure supported by the Linux file-system
layer. The actual i-node structure contains many more fields, since the same struc-
ture is also used to represent directories, devices, and other special files. The i-
node structure also contains fields reserved for future use.
History has shown that
unused bits do not remain that way for long.
Field
Bytes
Description
Mode
2
File type, protection bits, setuid, setgid bits
Nlinks
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)
Figure 10-33.
Some fields in the i-node structure in Linux.
Let us now see how the system reads a file. Remember that a typical call to the
library procedure for invoking the
read
system call looks like this:
n = read(fd, buffer, nbytes);
When the kernel gets control, all it has to start with are these three parameters and
the information in its internal tables relating to the user. One of the items in the in-
ternal tables is the file-descriptor array.
It is indexed by a file descriptor and con-
tains one entry for each open file (up to the maximum number, usually defaults to
32).
The idea is to start with this file descriptor and end up with the corresponding
i-node. 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.
Ace your assessments! Get Better Grades
Browse thousands of Study Materials & Solutions from your Favorite Schools
Concordia University
Concordia_University
School:
Operating_Systems
Course:
Great resource for chem class. Had all the past labs and assignments
Leland P.
Santa Clara University
Introducing Study Plan
Using AI Tools to Help you understand and remember your course concepts better and faster than any other resource.
Find the best videos to learn every concept in that course from Youtube and Tiktok without searching.
Save All Relavent Videos & Materials and access anytime and anywhere
Prepare Smart and Guarantee better grades
Know more
Students also viewed documents
lab 18.docx
lab_18.docx
Course
Course
3
Module5QuizSTA2023.d...
Module5QuizSTA2023.docx.docx
Course
Course
10
Week 7 Test Math302....
Week_7_Test_Math302.docx.docx
Course
Course
30
Chapter 1 Assigment ...
Chapter_1_Assigment_Questions.docx.docx
Course
Course
5
Week 4 tests.docx.do...
Week_4_tests.docx.docx
Course
Course
23
Week 6 tests.docx.do...
Week_6_tests.docx.docx
Course
Course
106
