Questions: File System Implementation

Question 1

You create two hard links — 'report.pdf' and 'final.pdf' — pointing to the same file. You then delete 'report.pdf.' What happens to the file data?

• A. The file data is immediately deleted when the first link is removed
• B. The file data is preserved because 'final.pdf' has its own independent copy of the data
• C. The file data is preserved because 'final.pdf' still references the same inode, and the inode's link count is now 1
• D. The file data becomes inaccessible but remains on disk until the next garbage collection cycle

Answer: (C)

Hard links work because filenames and file data are separate. Both 'report.pdf' and 'final.pdf' are directory entries pointing to the same inode. The inode maintains a link count. Deleting 'report.pdf' decrements the link count to 1 — the inode and data blocks are only freed when the link count reaches 0. 'final.pdf' still points to the same inode, so the data is fully intact and accessible. This is only possible because the inode stores everything EXCEPT the filename.

Question 2

Which file allocation method best supports efficient random access to an arbitrary byte within a large file?

• A. Linked allocation — each block can be placed anywhere, reducing seek time
• B. Contiguous allocation — the block containing any byte can be computed directly from the byte offset
• C. FAT (File Allocation Table) — the allocation table is cached in memory, making traversal fast
• D. Linked allocation with doubly-linked pointers — backward traversal halves average seek time

Answer: (B)

Contiguous allocation allows direct computation: byte N is at disk block (start_block + N/block_size). No traversal is needed — it's O(1). Linked allocation and FAT require traversing a chain from the beginning to reach block k, taking O(k) time. Indexed allocation (inodes) is also efficient for random access (follow one or two levels of indirect pointers), but contiguous allocation is the simplest and fastest. Linked allocation's advantage is dynamic growth and no external fragmentation, not random access speed.

Question 3

In a Unix file system, the inode stores the file's permissions, owner, timestamps, size, and pointers to data blocks — but NOT the filename.

• T. True
• F. False

Answer: True

The separation of filenames from inodes is a fundamental Unix design decision. Filenames live in directory entries, which are themselves files mapping names to inode numbers. This separation is what makes hard links possible: multiple directory entries in different locations can all point to the same inode, sharing a single file's data. If the filename were stored in the inode, a file could only have one name.

Question 4

A disk showing file system fragmentation — where file blocks are scattered non-contiguously — means the storage device is nearly full.

• T. True
• F. False

Answer: False

Fragmentation and fullness are independent. A disk with 90% free space can be heavily fragmented if files have been created and deleted repeatedly, leaving scattered free blocks too small for new files. Conversely, a nearly full disk might have its remaining files stored contiguously. Fragmentation is a problem of free-space distribution and allocation method, not of total available space.

Question 5

Explain why hard links are possible in Unix file systems. What does their existence reveal about the relationship between filenames and file data?

Model answer: Hard links are possible because filenames and file data are stored separately. File data is managed by an inode (index node), which contains metadata and pointers to data blocks. Filenames exist only in directory entries, which map a name string to an inode number. Multiple directory entries can reference the same inode number — these are hard links. This reveals that a 'file name' is not an intrinsic property of the data; it's just a label in a directory that happens to point to an inode.

The inode-directory separation is one of the most elegant design decisions in Unix. It means 'a file' is really the inode, not the name. Any number of names can refer to the same inode. The inode is only reclaimed when its link count drops to zero (all names removed) AND no process has it open. This design also explains why moving a file within the same file system is fast — it just updates directory entries, not data blocks.