One way to use file system's allocation of a disk and not suffer from holes is to compact the disk (i.e., move the files together to remove the holes) every time a file is deleted. Since all files are contiguous, copying a file requires a seek and rotational delay to read the file, followed by the transfer at full speed. Writing the file back requires the same work. Assuming a seek time of 6ms, a rotational delay of 4ms, a transfer rate of 5MB/sec, and an average file size of 8KB, how long does it take to read a file into main memory and then write it back to the disk at a new location? Using these numbers, how long would it take to compact half of a 16GB disk?
[Answer]
Read and write time for a file = 2 * (seek time + rotational delay + transfer time)
Seek time = 6 ms Rotational delay = 4 ms Transfer rate = 5MB/sec = 5 * 1024 KB/sec ( 5000 KB/sec is OK too) Average file size = 8KB Transfer time = 8/(5*1024) s (8/5000 s is OK too) Transfer time = 1.5625 ms (1.6 ms is OK too) Overall time = 6 + 4 + 1.5625 = 11.5625 ms (11.6 ms is OK too) Read and write time = 2 * 11.5625 = 23.125 ms (23.2 ms is OK too) A 16 GB disk = (approx) 1,000,000 * 16 KB The number of files that Half of 16 GB disk can have: (1024 * 1024 * 16 KB * 0.5)/8KB = 1,048,576 KB (1,000,000 is OK) Assuming we have to move all the files during the compaction, the maximum time taken = 23.125 * 1,048,576 = 24,248,320 ms = 24,248 s (23,125 s is OK)
In light of the answer to the previous question, does compacting the disk ever make sense? Explain your answer.
[Answer]
Compacting a disk after every file removal is a very time consuming job. In the example above every file removal if followed by a disk compaction might take hours to finish. But if a 16GB disk is occupied using only half the disk and the rest of the disk is being wasted as holes. In this situation, a disk compaction may make sense although it takes a long time. The advantage would be that the free space could be useful.
Two computer science students, John and Mary, are having a discussion about i-nodes. John maintains that memories have gotten so large and so cheap that when a file is opened, it is simpler and faster just to fetch a new copy of the i-node into the i-node table, rather than search the entire table to see is it is already there. Mary disagrees. Who is right? Justify your answer.
[ANSWER]
Mary is right because it takes a lot of time to fetch the i-node from the disk every time it is needed. Also when a process is using a file the i-node of the file would be in memory and any changes made to the i-node might not have been written back to the disk. This causes consistency problems.
List four ways a system could use to determine which blocks on a disk are free.
Give advantages of each way.
[ANSWER]
[ANSWER]
[ANSWER]
What are the advantages and disadvantages of recording the name of the creating program with the file's attributes (as is done in the Macintosh operating system)?
[ANSWER]
Advantage: If the name of the creating program is recorded with the
file's attributes, then the operating system knows exactly which program should be invoked automatically in order to load the file.
Disadvantage: The operating system needs to implement extra
functionality (to set the correct attribute during the create () call) so that
the attribute's use is enforced and supported by the system. Also there is
lack of flexibility.
Suppose that an inode is 128 bytes, pointers are 4 bytes long, and
the status information takes up 68 bytes. Assume a block size of
8K bytes and block pointers of 32 bits each.
(a) How much room is there for direct pointers in the inode?
(b) How big a file can be represented with direct pointers?
(c) How big a file can be represented with single Indirect pointers?
(d) How big a file can be represented with Double Indirect pointers?
(e) How big a file can be represented with Triple Indirect pointers?
[ANSWER]
(8KB = 8192 bytes) The single, double, and triple indirect pointers take 4 bytes each, so 128(total) - 68(status) - 12(indirect) = 48 Therefore 48 bytes are available for direct pointers. 48/4 = 12 direct pointers can be implemented. Thus a file size of 12 x 8192 = 98,304 bytes can be represented solely with direct pointers. If the block size is 8K bytes, the single indirect pointer addresses an 8K block that can hold 8192 / 4 = 2048 pointers to data blocks. Thus, the single indirect pointer provides the capability of addressing an additional 2048 x 8192 = 16,777,216 bytes (or 16 MB) of information. Double indirect addressing provide 2048 x 2048 pointers with the capability of addressing 2048 x 2048 x 8192 = 32 GB (additional to the 98KB + 16MB) Triple indirect addressing provides 2048 x 2048 x 2048 pointers with the capability of addressing an additional 2048 x 2048 x 2048 x 8192 = 64 terabytes.
Consider a system that supports 5000 users. Suppose you want to allow 4990 of these users to be able to access one file. How would you specify this protection scheme in UNIX?
[ANSWER]
A new group of the 4990 users must be created and associated with the file to
be accessed. The owner of the file can then set the access rights for the
group (whether the group can read, write and execute the file).
Consider the following backup scheme:
[ANSWER]
Consider a file system on a disk that has both logical and physical block sizes of 512 bytes. Assume that the information about each file is already in memory and each disk address contains 1 bytes. For each of the three allocation strategies (Contiguous, linked, and indexed), answer these questions:
[ANSWER]
The logical block number of a file always starts at 1.
Let Z be the starting file address for physical block number, then the last
physical block would be:
Contiguous:
Divide the logical address by 512 with X and Y the resulting quotient and
remainder respectively.
How many disk operations are needed to fetch the i-node for the file /home/teacher/courses/os/handout.html? Explain your answer. Assume that the root directory is in memory, but nothing else along the path is in memory. Assume also that each directory file fits in one block.
[ANSWER]
The root directory is in memory. Therefore there is no need for a disk access.
But, none of the other elements in the path are in memory.
For each of the directories home, teacher, courses and os, two disk operations
will be needed. One for loading the inode and the second to load the directory
file (data for the directory file). Finally, one disk operation will be required
to load the inode for handout.html file.
Thus in all, 9 disk operations will be required to fetch the file
/home/teacher/courses/os/handout.html.