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.
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.
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.
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% |