Page 446 - DCAP103_Principle of operating system
P. 446
Unit 14: Case Study of Linux Operating System
reading from the k-th byte on the corresponding partition, completely ignoring the i-node Notes
and file structure. Raw block devices are used for paging and swapping, by programs that lay
down file systems (e.g., mkfs), and by programs that fix sick file systems (e.g., fsck), for example.
Many computers have two or more disks. On mainframes at banks, it is frequently necessary
to have 100 or more disks on a single machine, in order to hold the huge databases required.
Even personal computers normally have at least two disks—a hard disk and an optical (e.g.,
DVD) drive. When these are multiple disk drives, the question arises of how to handle them.
One solution is to put a self-contained file system on each one and just keep them separate.
Consider, the situation depicted in Figure 14.25.
Here we have a hard disk, which we will call C:, and a DVD, which we will call D, each has its own
root directory and files. With this solution, the user has to specify both the device and the file when
anything other than the default is needed. For example, to copy the file x to the directory d, (assuming
C: is the default), one would type cp D:/x /a/d/x. This is the approach taken by systems like
MS-DOS, Windows 98, and VMS. The Linux solution is to allow one disk to be mounted in
another disk’s file tree. In this example, we could mount the DVD on the directory /b, yielding
the file system of Figure 14.25. The user now sees a single file tree, and no longer has to be
aware of which file resides on which device.
Figure 14.25: (a) Separate File Systems and (b) After Mounting
Another interesting property of the Linux file system is locking. In some applications, two or
more processes may be using the same file at the same time, which may lead to race conditions.
One solution is to program the application with critical regions. However, if the processes belong
to independent users who do not even know each other, this kind of coordination is generally
inconvenient. Consider, for example, a database consisting of many files in one or more directories
that are accessed by unrelated users. It is certainly possible to associate a semaphore with each
directory or file and achieve mutual exclusion by having processes do a down operation on the
appropriate semaphore before accessing the data. The disadvantage, however, is that a whole
directory or file is then made inaccessible, even though only one record may be needed.
For this reason, POSIX provides a flexible and fine-grained mechanism for processes to lock
as little as a single byte and as much as an entire file in one indivisible operation. The locking
mechanism requires the caller to specify the file to be locked, the starting byte, and the number
of bytes. If the operation succeeds, the system makes a table entry noting that the bytes in
question (e.g., a database record) are locked. Two kinds of locks are provided, shared locks
and exclusive locks. If a portion of a file already contains a shared lock, a second attempt to
place a shared lock on it is permitted, but an attempt to put an exclusive lock on it will fail. If a
portion of a file contains an exclusive lock, all attempts to lock any part of that portion will fail
until the lock has been released. In order to successfully place a lock, every byte in the region
to be locked must be available.
LOVELY PROFESSIONAL UNIVERSITY 439