Tutorial Week 7

Questions

Files and file systems

Q1: The Unix inode structure contains a reference count. What is the reference count for? Why can't we just remove the inode without checking the reference count when a file is deleted?

Q2: Inode-based filesystems typically use block groups. Each block group consists of a number of contiguous physical disk blocks. Inodes for a given block group are stored in the same physical location as the block groups. What are the advantages of this scheme? Are they any disadvantages?

Q3: Assume an inode with 10 direct blocks, as well as single, double and triple indirect block pointers. Taking into account creation and accounting of the indirect blocks themselves, what is the largest possible number of block reads and writes in order to:

  1. Read 1 byte
  2. Write 1 byte

Assume the inode is cached in memory.


Q4: Assume you have an inode-based filesystem. The filesystem has 512 byte blocks. Each inode has 10 direct, 1 single indirect, 1 double indirect, and 1 triple indirect block pointer. Block pointers are 4 bytes each. Assume the inode and any block free list is always in memory. Blocks are not cached.

  1. What is the maximum file size that can be stored before
    1. the single indirect pointer is needed?
    2. the double indirect pointer is needed?
    3. the triple indirect pointer is needed?
  2. What is the maximum file size supported?
  3. What is the number of disk block reads required to read 1 byte from a file
    1. in the best case?
    2. in the worst case?
  4. What is the number of disk block reads and writes required to write 1 byte to a file
    1. in the best case?
    2. in the worst case?


Q5: A typical UNIX inode stores both the file's size and the number of blocks currently used to store the file. Why store both? Should not blocks = size / block size?


Q6: Why does Linux divide a partition up into smaller block groups?


Q7: How can deleting a file corrupt a inode-based file system (like ext2fs in Linux).


Q8: How does adding journalling to a file system avoid corruption in the presence of unexpected power failures.