OPERATING SYSTEM IMPORTANT QUESTION ANSWER PART 3
for IGNOU BCA MCA Students
34. Filesystems can support sparse files, what does this mean? Give an example of an application's file organisation that might benefit from a file system's sparse file support.
A sparse file is a file that has a start, and end, but no middle. The bytes in between the starting set and the ending set are simply unused. An application that may benefit from sparse file support might be a virtualisation platform, in which it presents the user with an "empty" virtual hard drive. Another is a partially completed file accessed via the BitTorrent Protocol.
35. Give an example of a scenario that might benefit from a file system supporting an append-only access write.
An application where an append-only access write would be useful could be a "drop box" to hand in finished assignments where no further adjustments can be made. Another could be a very rudimentary version control system in which every single revision of the file is stored in full. A third could be a log file, where append-only prevents editing existing log entries.
36. Give a scenario where choosing a large filesystem block size might be a benefit; give an example where it might be a hinderance.
Large file system block sizes are a help (where performance is concerned) when the files in question are very large, and contiguous reading/writing is prevalent. For example, multimedia files. A large file system block size, unfortunately, wastes a lot of space if your file system largely consists of small sized files. Random access to small segments of data require loading entire blocks of data, even though you only need a small amount of it.
37. Give an example where contiguous allocation of file blocks on disks can be used in practice.
Contiguous allocation of file blocks on disks can be used when you're writing a memory dump (of your known 2GB or so of memory) because your OS crashed ;) Jesting aside, contiguous allocation is painful because it is necessary to know the file's final size prior to even allocating any space. It is still used on write-once optical media, because prior to burning your CD, DVD or BD the system knows exactly how much space each file uses on said disk.
38. What file access pattern is particularly suited to chained file allocation on disk?
Chained, or 'Linked List' allocation, like contiguous allocation, is useful for when dealing with large, sequential files. The first word of each block is used to point to the next one in sequence. It is fine for sequential access because every block needs to be read regardless. It's a living nightmare for random access files because we introduce a lot of unnecessary, wasted "read" operations to the FS.
39. What file allocation strategy is most appropriate for random access files?
An inode (indexed node) based file allocation strategy. It is a form of file allocation table that offers temporal locality – the inode only needs to be located in memory when its corresponding file is open. The inode is a data structure which lists all attributes and points to all the addresses of the disk blocks corresponding to that file.
40. Compare bitmap-based allocation of blocks on disk with a free block list.
The two methods of managing free space on the inode-based system are:
- Linked List of free blocks – the pointers are stored in the free blocks themselves, only a block of pointers needs to be kept in main memory. Advantageous in that it gets smaller as the disk is used up.
- Bitmap Allocation – individual bits in a bit vector flags used and free blocks, but is large and of a fixed size as it corresponds to the entire disk (perhaps too large to hold in main memory) and expensive to search. However, it's simple to find contiguous free space.
41. How can the block count in an inode differ from the (file size / block size) rounded up to the nearest integer. Can the block count be greater, smaller, or both.
Block count frequently differs from file size. File size is the offset of the highest byte written, and is what you commonly notice in files that you deal with everyday. Block count is a count of the number of physical disk blocks that are used by the file. In the example of a sparsely populated file, such as a BitTorrent download of a 700 MB Linux ISO – it uses up '700 MB' on your system at the beginning, long before the actual 700 MB of the file's contents are actually written to your disk blocks. However, most files are non sparse and disk block usage should be equal to file size. In reality, disk block usage is actually a little higher, as there are additional blocks (metadata, etc) not considered in the file size. Therefore disk block count can differ in any way from the file size, or even be equal with the right trade- off between sparsity and additional block usage.
42. Why might the direct blocks be stored in the inode itself?
To adhere to the principle of spatial locality – we can avoid extra disk seek operations simply by reading/writing to the first "spare" 12 blocks of the inode – there's plenty of room in it, and it makes the inode space not a complete waste of disk blocks.
43. Given that the maximum file size of combination of direct, single indirection, double indirection, and triple indirection in an inode-based filesystem is approximately the same as a filesystem solely using triple indirection, why not simply use only triple indirection to locate all file blocks?
Did you not read the answer to Question 42?! Spatial locality! For smaller files, it keeps the amount of disk accesses (which are expensive, given that there is a mechanical component otherwise known as the disk head) low to read any block in the file. The amount of disk accesses grows with the levels of indirection we have – a direct block only requires one operation to read, a single indirection requires 2 operations (one for the indirect block, one of the block it's pointing to), and so on.
44. What is the maximum file size supported by a file system with 16 direct blocks, single, double, and triple indirection? The block size is 512 bytes. Disk block numbers can be stored in 4 bytes.
Number of blocks:
- Direct Blocks = 16 blocks
- Single Indirect Blocks = 512 / 4 = 128 blocks
- Double Indirect Blocks = 128 * 128 = 16384 blocks
- Triple Indirect Blocks = 128 * 128 * 128 = 2097152 blocks
Total number of blocks = direct + single + double + triple = 16 + 128 + 16384 + 2097152 = 2113680
Total number of bytes = 2113680 * 512 = 1.08220416 E 9 = 1.08 GB
No comments:
Post a Comment