|
|
|
Modern Operating Systems by Herbert Bos and Andrew S. Tanenb...
Modern_Operating_Systems_by_Herbert_Bos_and_Andrew_S._Tanenbaum_4th_Ed.pdf
Showing 341-342 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 341
310
FILE SYSTEMS
CHAP. 4
1
18
19
5
6
27
7
10
20
22
30
29
23
14
11
2
3
4
8
9
12
13
15
31
28
32
24
25
26
16
17
21
File that
has changed
File that has
not changed
Root directory
Directory
that has not
changed
Figure 4-25.
A file system to be dumped. The squares are directories and the cir-
cles are files. The shaded items have been modified since the last dump. Each di-
rectory and file is labeled by its i-node number.
restored first. To get their owners, modes, times, and whatever, correct, these di-
rectories must be present on the dump disk even though they themselves were not
modified since the previous full dump.
The dump algorithm maintains a bitmap indexed by i-node number with sever-
al bits per i-node. Bits will be set and cleared in this map as the algorithm pro-
ceeds. The algorithm operates in four phases. Phase 1 begins at the starting direc-
tory (the root in this example) and examines all the entries in it. For each modified
file, its i-node is marked in the bitmap.
Each directory is also marked (whether or
not it has been modified) and then recursively inspected.
At the end of phase 1, all modified files and all directories have been marked in
the bitmap, as shown (by shading) in Fig. 4-26(a). Phase 2 conceptually recur-
sively walks the tree again, unmarking any directories that have no modified files
or directories in them or under them. This phase leaves the bitmap as shown in
Fig. 4-26(b).
Note that directories 10, 11, 14, 27, 29, and 30 are now unmarked be-
cause they contain nothing under them that has been modified. They will not be
dumped. By way of contrast, directories 5 and 6 will be dumped even though they
themselves have not been modified because they will be needed to restore today’s
changes to a fresh machine. For efficiency, phases 1 and 2 can be combined in one
tree walk.
At this point it is known which directories and files must be dumped. These are
the ones that are marked in Fig. 4-26(b). Phase 3 consists of scanning the i-nodes
in numerical order and dumping all the directories that are marked for dumping.
Page 342
SEC. 4.4
FILE-SYSTEM MANAGEMENT AND OPTIMIZATION
311
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
(d)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
(c)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
(b)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
(a)
Figure 4-26.
Bitmaps used by the logical dumping algorithm.
These are shown in Fig. 4-26(c). Each directory is prefixed by the directory’s at-
tributes (owner, times, etc.) so that they can be restored. Finally, in phase 4, the
files marked in Fig. 4-26(d) are also dumped, again prefixed by their attributes.
This completes the dump.
Restoring a file system from the dump disk is straightforward. To start with,
an empty file system is created on the disk.
Then the most recent full dump is re-
stored. Since the directories appear first on the dump disk, they are all restored
first, giving a skeleton of the file system. Then the files themselves are restored.
This process is then repeated with the first incremental dump made after the full
dump, then the next one, and so on.
Although logical dumping is straightforward, there are a few tricky issues. For
one, since the free block list is not a file, it is not dumped and hence it must be
reconstructed from scratch after all the dumps have been restored. Doing so is al-
ways possible since the set of free blocks is just the complement of the set of
blocks contained in all the files combined.
Another issue is links.
If a file is linked to two or more directories, it is impor-
tant that the file is restored only one time and that all the directories that are sup-
posed to point to it do so.
Still another issue is the fact that UNIX files may contain holes.
It is legal to
open a file, write a few bytes, then seek to a distant file offset and write a few more
bytes. The blocks in between are not part of the file and should not be dumped and
must not be restored. Core files often have a hole of hundreds of megabytes be-
tween the data segment and the stack.
If not handled properly, each restored core
file will fill this area with zeros and thus be the same size as the virtual address
space (e.g., 2
32
bytes, or worse yet, 2
64
bytes).
Finally, special files, named pipes, and the like (anything that is not a real file)
should never be dumped, no matter in which directory they may occur (they need
not be confined to
/dev
). For more information about file-system backups, see
Chervenak et al., (1998) and Zwicky (1991).
Ace your assessments! Get Better Grades
Browse thousands of Study Materials & Solutions from your Favorite Schools
Concordia University
Concordia_University
School:
Operating_Systems
Course:
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
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