12 thoughts on “Tutorial 10: Solution”

  1. Hi Prof Ooi,

    For question 2:
    Can we argue that since flash memory access memory in the random fashion, there is not much advantage in contiguous allocation. Also holes can be created since user may delete the photos after reviewing them.

    Also for video recorder, since the recording is done contiguously as the files return are videos. Even if user deletes the videos, they will be most likely done in a FIFO manner as the user deletes them after watching. The holes are likely to be contiguous. The writing of files hence behaves like a circular queue. In this case, contiguous allocation is a good scheme.

    • Yun Long,

      Yes, both arguments make sense.

      This question is quite open ended and depends on what your assumptions are.

  2. With regards to Question 4b, I would like to ask whether if this approach of seeing is valid. If not, why is it wrong? The approach of seeing is as such:

    While moving a file to a current disk partition means copying all files to that new partition and upon success, deletion. However, if I’m not wrong that deletion is just the removal of the directory entry on the disk and not the actual file itself right? A file is not fully inaccessible if not ask links to it are removed right? Thus, shouldn’t an upload program still has the link to the file?

    • I think the link you meant refers to the directory entry in the directory. If no more directory entries are pointing to the inode of the file, then its space is freed from the system.

      The upload program refers to the file but it does not have a link to the file. It merely opens the file to be read. It does not create another directory to link to the file, therefore the moving of the file to another partition is invalid.

    • Raymond,

      Deleting a file also marks its data blocks and its i-node as “free” so that the OS can re-use them for other new files.

      So moving by copying then deleting does not work.

  3. Dear Prof Ooi,

    I would like to clarify my understanding on Qn3.

    For the cons, one of the reason stated in the solution: “The whole block is used even when file is very small (e.g., empty file, or a device file that does not occupy disk space).”.

    i-node is a data structure used to store the disk blocks used by each file. Since one i-node is assigned to each file, isn’t it true that the whole block is used even when file is small? Why does this only apply to i-node when it is stored at the first byte of the file?

    Thank you.
    Your Sincerely,
    Loke Yan Hao

    • When your inodes are stored in a table at the start of the disk, if you have a file that does not occupy disk space, you do not have to allocate any blocks for the file’s contents. That is, only the inode table entry needs to be filled up, with the pointers to the blocks set to point to nothing. Since your inodes are stored in a compact manner (in a table at the start of the disk), you do not waste space (remember that there are many inodes per block in that table).

      On the other hand, if your inodes are stored at the start of the first block, then each file requires at least one block on the disk, even if it does not contain any data, for the storage of the inode. That is, you are unable to compactly store the inodes (since the addressing scheme requires the inodes for different files to be in unique blocks).

      • Yes. Basically if you store all i-nodes together, you can fill up a block with only i-nodes — so less internal fragmentation.

  4. Q3: In this scheme, the OS would still need to maintain a data structure for locating inodes. So wouldn’t there still be an upper bound for the number of inodes (which is the number of entries in this data structure)? Unless it is implemented as a dynamically growing data structure, I suppose.

    Q4b: My answer is the same as the given solution, but I was wondering if it works differently in real systems. Is it the case that when files are opened, the inode count is increased (and correspondingly decreased when closed) so that when a user tries to remove a file while it is in use by some process, the inode is only invalidated (and its blocks freed) when the process is done with the file? That is to say, do real operating systems make it possible to perform the actions in (b)?

    • Q3: We can keep track of i-nodes location in the directory entries. In each entry, instead of storing the i-node number, we store the first block address instead.

      Q4: Good point. It depends on the implementation. On some OSes, you are not allowed to remove an open file. On some, you can move the file to Trash, but not allowed to delete it immediately.

      Note that the behavior you described can be annoying, because a user might want to delete a large file to clear some disk space, but a background process might have the file opened (e.g., indexing process, backup process) so the file is not really deleted until later. (Have you experience trying to eject a disk, and the OS tells you cannot because someone has opened a file on the diskbut you do not know who? It’s the same problem)

Comments are closed.