K L University

Department of Computer Science & Engineering

Course Name : Operating Systems

1)

Write about the Prototypical System Architecture 3m

a single CPU attached to the main memory of the system via some kind of memory bus or interconnect. Some devices are
connected to the system via a general I/O bus, which in many modern systems would be PCI (or one of its many
derivatives); graphics and some other higher-performance I/O devices might be found here. Finally, even lower down are
one or more of what we call a peripheral bus, such as SCSI, SATA, or USB. These connect the slowest devices to the system,
including disks, mice, and other similar components.

we need a hierarchical structure like this to Put simply: physics, and cost. The faster a bus is, the shorter it must be; thus, a
high-performance memory bus does not have much room to plug devices and such into it. In addition, engineering a bus for
high performance is quite costly. Thus, system designers have adopted this hierarchical approach, where components that
demand high performance (such as the graphics card) are nearer the CPU. Lower performance components are further
away. The benefits of placing disks and other slow devices on a peripheral bus are manifold; in particular, you can place a
large number of devices on it.

Write about the Files and Directories with an Example Directory Tree 3M

A file is simply a linear array of bytes, each of which you can read or write. Each file has some kind of low-level name of a
file is often referred to as its inode number. the file system is simply to store such data persistently on disk and make sure
that when you request the data again, you get what you put there in the first place.
A directory, like a file, also has a low-level name (i.e., an inode number), but its contents are quite specific: it contains a list
of (user-readable name, low-level name) pairs. For example, lets say there is a file with the low-level name 10, and it is
referred to by the user-readable name of foo. The directory that foo resides in thus would have an entry (foo, 10)
that maps the user-readable name to the low-level name. Each entry in a directory refers to either files or other directories.
By placing directories within other directories, users are able to build an arbitrary directory tree (or directory hierarchy),
under which all files and directories are stored

The directory hierarchy starts at a root directory (in UNIX-based systems, the root directory is simply referred to as /) and
uses some kind of separator to name subsequent sub-directories until the desired file or directory is named. For example, if
a user created a directory foo in the root directory /, and then created a file bar.txt in the directory foo, we could refer to
the file by its absolute pathname, which in this case would be /foo/bar.txt. for a more complex directory tree; valid
directories in the example are /, /foo, /bar, /bar/bar, /bar/foo and valid files are /foo/bar.txt and /bar/foo/bar.txt.
Directories and files can have the same name as long as they are in different locations in the file-system tree (e.g., there are
two files named bar.txt in the figure, /foo/bar.txt and /bar/foo/bar.txt).

Illustrate how to ensure DATA INTEGRITY 4m

Data integrity is a fundamental aspect of storage security and reliability. With the advent of network storage and new
technology trends that result in new failure modes for storage, interesting challenges arise in ensuring data integrity. The
primary mechanism used by modern storage systems to preserve data integrity is called the checksum. A checksum is
simply the result of a function that takes a chunk of data (say a 4KB block) as input and computes a function over said data,
producing a small summary of the contents of the data (say 4 or 8 bytes). This summary is referred to as the checksum. The
goal of such a computation is to enable a system to detect if data has somehow been corrupted or altered by storing the
checksum with the data and then confirming upon later access that the datas current checksum matches the original
storage value. A number of different functions are used to compute checksums, and vary in strength.
2)

Write about Efficient Data Movement with DMA 3m

when using programmed I/O (PIO) to transfer a large chunk of data to a device, the CPU is once again overburdened with a
rather trivial task, and thus wastes a lot of time and effort that could better be spent running other processes. This timeline
illustrates the problem:

In the timeline, Process 1 is running and then wishes to write some data to the disk. It then initiates the I/O, which must
copy the data from memory to the device explicitly, one word at a time (marked c in the diagram). When the copy is
complete, the I/O begins on the disk and the CPU can finally be used for something else.

The solution to this problem is something we refer to as Direct Memory Access (DMA). A DMA engine is essentially a very
specific device within a system that can orchestrate transfers between devices and main memory without much CPU
intervention.

To transfer data to the device, for example, the OS would program the DMA engine by telling it where the data lives in
memory, how much data to copy, and which device to send it to. At that point, the OS is done with the transfer and can
proceed with other work. When the DMA is complete, the DMA controller raises an interrupt, and the OS thus knows the
transfer is complete. The revised timeline:

From the timeline, you can see that the copying of data is now handled by the DMA controller. Because the CPU is free
during that time, the OS can do something else, here choosing to run Process 2. Process 2 thus gets to use more CPU before
Process 1 runs again.

Explain about Writing Immediately with fsync() Strace code 3m

In UNIX , the interface provided to applications is known as fsync(int fd). When a process calls fsync() for a particular file
descriptor, the file system responds by forcing all dirty (i.e., not yet written) data to disk, for the file referred to by the
specified e. Here is a simple example of how to use fsync(). The code opens the file foo, writes a single chunk of data to it,
and then calls fsync() to ensure the writes are forced immediately to disk. Once the fsync() returns, the application can
safely move on, knowing that the data has been persisted

int fd = open("foo", O_CREAT|O_WRONLY|O_TRUNC, S_IRUSR|S_IWUSR); assert(fd > -1);

int rc = write(fd, buffer, size);

rc = fsync(fd);

assert(rc == 0);

Write about the Handling Latent Sector Errors 4m

Latent sector errors are rather straightforward to handle, as they are easily detected. When a storage system tries to access
a block, and the disk returns an error, the storage system should simply use whatever redundancy mechanism it has to
return the correct data. In a mirrored RAID, for example, the system should access the alternate copy; in a RAID-4 or RAID-5
system based on parity, the system should reconstruct the block from the other blocks in the parity group. Thus, easily
detected problems such as LSEs are readily recovered through standard redundancy mechanisms.

An interesting problem arises in RAID-4/5 systems when both full-disk faults and LSEs occur in tandem. Specifically, when
an entire disk fails, the RAID tries to reconstruct the disk (say, onto a hot spare) by reading through all of the other disks in
the parity group and recomputing the missing values. If, during reconstruction, an LSE is encountered on any one of the
other disks, we have a problem: the reconstruction cannot successfully complete. some systems add an extra degree of
redundancy. When an LSE is discovered during reconstruction, the extra parity helps to reconstruct the missing block. As
always, there is a cost, in that maintaining two parity blocks for each stripe is more costly

3)

Imagine A Simple Disk Drive and explain about Single-track Latency: The Rotational Delay, Multiple Tracks:
Seek Time and Three Tracks Plus A Head (Right: With Seek). 3m

a simple disk with a single track (Figure 37.1). This track has just 12 sectors, each of which is 512 bytes in size (our typical
sector size, recall) and addressed therefore by the numbers 0 through 11. The single platter we have here rotates around
the spindle, to which a motor is attached. we want to be able to read or write those sectors, and thus we need a disk head,
attached to a disk arm. the disk head, attached to the end of the arm, is positioned over sector 6, and the surface is rotating
counter-clockwise.

Single-track Latency: The Rotational Delay

To understand how a request would be processed on our simple, onetrack disk, imagine we now receive a request to read
block 0. How should the disk service this request? We just wait for the desired sector to rotate under the disk head. This
wait happens often enough in modern drives, and is an important enough component of I/O service time, that it has a
special name: rotational delay (sometimes rotation delay, though that sounds weird). In the example, if the full rotational
delay is R, the disk has to incur a rotational delay of about R/2 to wait for 0 to come under the read/write head (if we start
at 6).

Multiple Tracks: Seek Time

the head is currently positioned over the innermost track (which contains sectors 24 through 35); the next track over
contains the next set of sectors (12 through 23), and the outermost track contains the first sectors (0 through 11).

a read to sector 11. To service this read, the drive has to first move the disk arm to the correct track (in this case, the
outermost one), in a process known as a seek. The seek, it should be noted, has many phases: first an acceleration phase as
the disk arm gets moving; then coasting as the arm is moving at full speed, then deceleration as the arm slows down; finally
settling as the head is carefully positioned over the correct track. The settling time is often quite significant, e.g., 0.5 to 2
ms, as the drive must be certain to find the right track. After the seek, the disk arm has positioned the head over the right
track. A depiction of the seek is found in Figure (right). As we can see, during the seek, the arm has been moved to the
desired track, and the platter of course has rotated, in this case about 3 sectors. Thus, sector 9 is just about to pass under
the disk head, and we must only endure a short rotational delay to complete the transfer. When sector 11 passes under the
disk head, the final phase of I/O will take place, known as the transfer, where data is either read from or written to the
surface. And thus, we have a complete picture of I/O time: first a seek, then waiting for the rotational delay, and finally the
transfer.

Write about Removing Files and show the strace 3m

we know how to create files and access them, either sequentially or not. But how do you delete files? If youve used UNIX,
you probably think you know: just run the program rm. But what system call does rm use to remove a file? Lets use our old
friend strace again to find out. Here we remove that pesky file foo:

prompt> strace rm foo ... unlink("foo") = 0 ...

Weve removed a bunch of unrelated cruft from the traced output, leaving just a single call to the mysteriously-named
system call unlink(). As you can see, unlink() just takes the name of the file to be removed, and returns zero upon success.
Analyze how to Handle Misdirected Writes 4m

adding a physical identifier (physical ID) is quite helpful. For example, if the stored information now contains the checksum
C(D) as well as the disk and sector number of the block, it is easy for the client to determine whether the correct
information resides within the block. Specifically, if the client is reading block 4 on disk 10 (D10,4), the stored information
should include that disk number and sector offset, as shown below. If the information does not match, a misdirected write
has taken place, and a corruption is now detected. Here is an example of what this added information would look like on a
two-disk system.

4)

Write about the Elevator (a.k.a. SCAN or C-SCAN)3m

Given the following queue -- 95, 180, 34, 119, 11, 123, 62, 64 with the Read-write head initially at the track 50 and the tail
track being at 199 let us now discuss the

SCAN, simply moves back and forth across the disk servicing requests in order across the tracks. Thus, if a request comes for
a block on a track that has already been serviced on this sweep of the disk, it is not handled immediately, but rather
queued until the next sweep

This approach works like an elevator does. It scans down towards the nearest end and then when it hits the bottom it scans
up servicing the requests that it didn't get going down. If a request comes in after it has been scanned it will not be serviced
until the process comes back down or moves back up. This process moved a total of 230 tracks. Once again this is more
optimal than the previous algorithm, but it is not the best.
Circular scanning works just like the elevator to some extent. It begins its scan toward the nearest end and works it way all
the way to the end of the system. Once it hits the bottom or top it jumps to the other end and moves in the same direction.
Keep in mind that the huge jump doesn't count as a head movement. The total head movement for this algorithm is only
187 track, but still this isn't the mose sufficient.

C-SCAN is another common variant, short for Circular SCAN. Instead of sweeping in both directions across the disk, the
algorithm only sweeps from outer-to-inner, and then resets at the outer track to begin again. Doing so is a bit more fair to
inner and outer tracks, as pure backand-forth SCAN favors the middle tracks, i.e., after servicing the outer track, SCAN
passes through the middle twice before coming back to the outer track again.

Explain about Hard Links with example 3m

The link() system call takes two arguments, an old pathname and a new one; when you link a new file name to an old
one, you essentially create another way to refer to the same file.

prompt> echo hello > file

prompt> cat file hello

prompt> ln file file2

prompt> cat file2 hello

Here we created a file with the word hello in it, and called the file file2 . We then create a hard link to that file using the ln
program. The way link works is that it simply creates another name in the directory you are creating the link to, and refers it
to the same inode numberof the original file. The file is not copied in any way; rather, you now just have two human names
(file and file2) that both refer to the same file. We can even see this in the directory itself, by printing out the inode number
of each file:

prompt> ls -i file file2

67158084 file

67158084 file2

prompt>
After creating a hard link to a file, to the file system, there is no difference between the original file name (file) and the
newly created file name (file2); indeed, they are both just links to the underlying metadata about the file, which is found in
inode number 67158084. Thus, to remove a file from the file system, we call unlink(). In the example above, we could for
example remove the file named file, and still access the file without difficulty:

prompt> rm file

removed file

prompt> cat file2 hello

The reason this works is because when the file system unlinks file, it checks a reference count within the inode number.
This reference count allows the file system to track how many different file names have been linked to this particular inode.
When unlink() is called, it removes the link between the human-readable name (the file that is being deleted) to the given
inode number, and decrements the reference count; only when the reference count reaches zero does the file system also
free the inode and related data blocks, and thus truly delete the file.

You can see the reference count of a file using stat() of course. Lets see what it is when we create and delete hard links to a
file. In this example, well create three links to the same file, and then delete them.the link count

prompt> echo hello > file

prompt> stat file

... Inode: 67158084 Links: 1 ...

prompt> ln file file2

prompt> stat file

... Inode: 67158084 Links: 2 ...

prompt> stat file2

... Inode: 67158084 Links: 2 ...

prompt> ln file2 file3

prompt> stat file

... Inode: 67158084 Links: 3 ...

prompt> rm file

prompt> stat file2

... Inode: 67158084 Links: 2 ...

prompt> rm file2

prompt> stat file3

prompt> rm file3

When to utilize disk scrubbing 4m

some amount of checking occurs when data is accessed by applications, but most data is rarely accessed, and thus would
remain unchecked. Unchecked data is problematic for a reliable storage system, as bit rot could eventually affect all copies
of a particular piece of data. To remedy this problem, many systems utilize disk scrubbing. By periodically reading through
every block of the system, and checking whether checksums are still valid, the disk system can reduce the chances that all
copies of a certain data item become corrupted. Typical systems schedule scans on a nightly or weekly basis.

5)

Explain about Interface And RAID Internals 3m

To a file system above, a RAID looks like a big, (hopefully) fast, and (hopefully) reliable disk. Just as with a single disk, it
presents itself as a linear array of blocks, each of which can be read or written by the file system (or other client). When a
file system issues a logical I/O request to the RAID, the RAID internally must calculate which disk (or disks) to access in order
to complete the request, and then issue one or more physical I/Os to do so. The exact nature of these physical I/Os
depends on the RAID level. However, as a simple example, consider a RAID that keeps two copies of each block (each one
on a separate disk); when writing to such a mirrored RAID system, the RAID will have to perform two physical I/Os for every
one logical I/O it is issued. A RAID system is often built as a separate hardware box, with a standard connection (e.g., SCSI,
or SATA) to a host. Internally, however, RAIDs are fairly complex, consisting of a microcontroller that runs firmware to
direct the operation of the RAID, volatile memory such as DRAM to buffer data blocks as they are read and written. At a
high level, a RAID is very much a specialized computer system: it has a processor, memory, and disks; however, instead of
running applications, it runs specialized software designed to operate the RAID.

Explain how the Access Paths: Reading and Writing is done with neat diagram 3m

Reading A File From Disk In this simple example, let us first assume that you want to simply open a file (e.g., /foo/bar), read
it, and then close it. For this simple example, lets assume the file is just 4KB in size (i.e., 1 block). When you issue an
open("/foo/bar", O RDONLY) call, the file system first needs to find the inode for the file bar, to obtain some basic
information about the file (permissions information, file size, etc.).
the open causes numerous reads to take place in order to finally locate the inode of the file. Afterwards, reading each block
requires the file system to first consult the inode, then read the block, and then update the inodes last-accessed-time field
with a write. Spend some time and try to understand what is going on.

Writing to Disk Writing to a file is a similar process. First, the file must be opened (as above). Then, the application can
issue write() calls to update the file with new contents. Finally, the file is closed

example, where the file /foo/bar is created, and three blocks are written to it. reads and writes to the disk are grouped
under which system call caused them to occur, and the rough ordering they might take place in goes from top to bottom of
the figure. You can see how much work it is to create the file: 10 I/Os in this case, to walk the pathname and then finally
create the file. You can also see that each allocating write costs 5 I/Os: a pair to read and update the inode, another pair to
read and update the data bitmap, and then finally the write of the data itself.

Illustrate about the Unreliable Communication Layers4m

an unreliable layer is found in the UDP/IP networking stack available today on virtually all modern systems. To use UDP, a
process uses the sockets API in order to create a communication endpoint; processes on other machines (or on the same
machine) send UDP datagrams to the original process (a datagram is a fixed-sized message up to some max size). UDP is a
great example of an unreliable communication layer. If you use it, you will encounter situations where packets get lost
(dropped) and thus do not reach their destination; the sender is never thus informed of the loss. However, that does not
mean that UDP does not guard against any failures at all. For example, UDP includes a checksum to detect some forms of
packet corruption. However, because many applications simply want to send data to a destination and not worry about
packet loss, we need more. Specifically, we need reliable communication on top of an unreliable network.
6)

Explain about the RAID Level 4 Saving Space With Parity 3m

Adding redundancy to a disk array known as parity. Parity-based approaches attempt to use less capacity and thus
overcome the huge space penalty paid by mirrored systems. They do so at a cost, however: performance.

Here is an example five-disk RAID-4 system. For each stripe of data, we have added a single parity block that stores the
redundant information for that stripe of blocks. For example, parity block P1 has redundant information that it calculated
from blocks 4, 5, 6, and 7. To compute parity, we need to use a mathematical function that enables us to withstand the loss
of any one block from our stripe. It turns out the simple function XOR does the trick quite nicely. For a given set of bits, the
XOR of all of those bits returns a 0 if there are an even number of 1s in the bits, and a 1 if there are an odd number of 1s.
For example:

In the first row (0,0,1,1), there are two 1s (C2, C3), and thus XOR of all of those values will be 0 (P); similarly, in the second
row there is only one 1 (C1), and thus the XOR must be 1 (P).

A file system with 300 GByte disk uses a file descriptor with 8 direct block addresses, 1 indirect block
address and 1 doubly indirect block address. The size of each disk block is 128 Bytes and the size of each
disk block address is 8 Bytes. The maximum possible file size in this file system is 3m

Total number of possible addresses stored in a disk block = 128/8 = 16

Maximum number of addressable bytes due to direct address block = 8*128

The maximum possible file size = 8*128 + 16*128 + 16*16*128 = 35KB

Unpack the message. This step, called unmarshaling or deserialization, takes the information out of the incoming
message. The function identifier and arguments are extracted.

Call into the actual function. Finally! We have reached the point where the remote function is actually executed. The RPC
runtime calls into the function specified by the ID and passes in the desired arguments.

Package the results. The return argument(s) are marshaled back into a single reply buffer.

Send the reply. The reply is finally sent to the caller.