Read inode for "/" Read data block for "/" Read inode for "usr" Read data block for "usr" Read inode for "include" Read data block for "include" Read inode for "X11" Read data block for "X11" Read inode for "Xlib.h" Read data block for "Xlib.h" 10 reads
We have 10 direct pointers that each point directly to a 4K data block, so we can point to 10 * 4K = 40K with the direct pointers.
We have one single-indirect pointer that points to a 4K disk block (an "index block") which contains nothing but pointers to data blocks. Since each disk block pointer is 4 bytes, the index block can hold 4K / 4 = 1K pointers to data blocks. So, the single-indirect pointer indirectly points to 1K * 4K = 4M (210 * 2 12 = 222 bytes).
We have one double-indirect pointer that points to an index block that contains 1K pointers to more index blocks. These leaf index blocks each contain 1K pointers to data blocks. So, the double-indirect pointer indirectly points to 1K * 1K * 4K = 4G (210 * 210 * 212 = 232 bytes).
Adding everything up, the maximum file size is 40K + 4M + 4G.
220 files * 2KB fragmentation per file = 220 * (2 * 210) = 230 * 2 = 231 = 2GB (any notation is fine)
220 files * 256 bytes of fragmentation per file = 220 * (28) = 228 = 256MB (any notation is fine)
There are many possible answers, all depending on the reasons for answering "yes" or "no". For example, your laptop disk may always be nearly filled to capacity, so an additional 1.75GB of extra disk space would be very useful. Alternatively, your laptop may have a large disk and you may never reach capacity, so an additional 1.75GB of disk space does not affect your use. The question is primarily about providing a reason one way or the other.
Consider a file archival system, like the programs zip or tar. Such systems copy files into a backup file and restore files from the backup. For example, from the zip documentation:
The zip program puts one or more compressed files into a single zip archive, along with information about the files (name, path, date, time of last modification, protection, and check information to verify file integrity).
When a file is restored, it is given the same name, time of last modification, protection, and so on. If desired, it can even be put into the same directory in which it was originally located.
Can zip restore the file into the same inode as well? Briefly explain your answer.
In general, the archive program cannot guarantee that the file will be restored to the same inode.
User programs like zip and tar use the logical file system (filenames and directories). inodes are part of the physical file system (superblock and inodes). The logical file system is built on top of the physical file system, and, in general, the kernel only provides a syscall interface for the logical file system.
So if an archive program wanted to guarantee that a file is restored to its original inode, it would have to write directly to the hard disk (bypassing the file system entirely), since there is no syscall interface to write to a particular inode. This means that the archive program would need root access, and it would need to understand the layout of the physical file system on the hard disk.
In particular, writing a file to its original inode becomes very difficult if the original inode is in use by some other file f. The archive program would have to relocate f to another inode, which is hard because the archive program would have to search the disk for all references to f's old inode, and make them all point to f's new inode. This is extremely difficult if the file system is mounted and there are other running processes that use the file system.
File caches improve performance by converting what would be disk I/O operations (read, write) into memory operations (reading from memory, writing into memory). For those operations that can be served from the cache (e.g., one user accessing "/usr/include/stdio.h" and then another user accessing it soon after), they operate at the speed of memory rather than the speed of disk. Since disk I/O is much slower than memory, reducing the number of disk I/Os substantially improves performance.
But there is always a tradeoff. In this case, the file buffer cache uses physical memory to store the file data. As a result, it reduces the amount of physical memory that the OS can use for mapping virtual pages. As more physical memory is used for the file buffer cache, less is used to store virtual pages and processes may start to page fault more. At some point, growing the file buffer cache will result in more disk I/O (for handling page faults) than the file buffer cache saves in caching file data. This situation reduces performance overall, which we want to avoid.
For various values of I and X, compute the percentage of time that the program spends waiting for I/O and fill in the following table. If I and X are both 1 ms, for example, then the program spends 50% of its time waiting for I/O.
| X | |||||
| 100 ms | 10 ms | 1 ms | 0.1 ms | ||
| 25 ms (cloud storage) | 20.0% | 71.4% | 96.2% | 99.6% | |
| 5 ms (HDD) | 4.76% | 33.3% | 83.3% | 98.0% | |
| I | 0.1 ms (SSD) | 0.0999% | 0.990% | 9.09% | 50.0% |
| 0.0005 ms (NVM) | 0.00050% | 0.0050% | 0.0500% | 0.498% | |
| 0.0001 ms (RAM) | 0.0001% | 0.0010% | 0.0100% | 0.0999% |
Consider a process running in a virtual machine. Assume that the virtual machine is running on a type 1 hypervisor with no modern hardware support for virtualization. For each of the following events, which system component(s) are involved in handling it? For each answer, choose from: the guest OS, the hypervisor, both, or neither. Briefly explain each answer.
Both the guest OS and the hypervisor. Writing to a file involves a write() system call. Normally this would cause a trap to the OS, but when our guest OS is running at user-level in a VM, this causes a trap to the hypervisor instead (trap and emulate). The hypervisor will then invoke the appropriate handler within the guest OS to execute the file-system logic and determine which block to write to. In order to actually write to the hardware disk, the hypervisor will be involved again.
Both the guest OS and the hypervisor. Similar to (a), exit() is a system call, which will trigger a trap to the hypervisor and the hypervisor will then invoke the guest OS's handler function. However, in contrast with (a), the guest OS can typically handle the exit() system call without further interactions with the hypervisor, because exit() does not usually involve privileged instructions or interactions with hardware devices.
The hypervisor. In this case the hypervisor has swapped a page out to disk without the guest OS's knowledge, so it can resolve the page fault by swapping the page back in, again without the guest OS's involvement. Thus the hypervisor can swap pages in and out in a way that is entirely transparent to the guest OS.
Neither. A context switch between two user-level threads occurs entirely at user level, which does not require OS or hypervisor involvement.
Both the guest OS and the hypervisor. This will trigger an exception, which will immediately cause a trap to the hypervisor. The hypervisor will call the guest OS's handler function to resolve it, similar to the case of exit() above.
The hypervisor. The hypervisor has control over VM scheduling and can switch from running one VM to running another in a way that is transparent to the VMs and to the guest OSes (unless they were to measure timing information).
The Unix file protection system allows users to specify protection at the granularity of a single user (owner), a group of users (group), and all users (other). To specify this policy on Unix, you would create a group with the 4990 users who are able to access the file and give the file the appropriate group permissions (e.g., read and write).
If we are not constrained by what Unix provides, more compact approaches would involve some way to specify who does not have access. One approach would be to extend the Unix group model to be able to list users who are not in the group. With this mechanism, you would create a group as before, but list the 10 users who should not get access. The file would then get the same group permissions, but the group would be interpreted differently.
Another approach would be to be able to specify negative permissions on a file. In this approach, you would create a group with the 10 users who should not access a file, and then assign group permissions on the file as negative permissions (e.g., users in this should group should not be able to access the file).
A third approach would be to have very flexible access control lists where you can associate an arbitrary number of access control entries (not just "owner", "group", "other"). In such a system, you could create access control entries for each of the 10 users specifying that they did not have access to the file, and then have a wildcard entry specifying that every other user (who does not specifically match the first 10) can access the file. (For those who have ever created a .htaccess file for Apache, you likely have done something like this with a "deny from all" or "accept from all".)
Note that this is technically a violation of the principle of "permission, not exclusion". Interestingly, it is still a useful method for addressing this situation because it makes it much easier to express protection intent — in this case, the "ease of use" principle outweighs the other.