File systems
Operating Systems · 10 interview questions
A file system organises blocks on a device into files and directories. In Unix-like systems the central structure is the inode, which holds a file's metadata and the pointers to its data blocks — but not its name. Names live in directory entries that map a name to an inode number, which is why one file can have several names.
Allocation strategy determines how a file's blocks are found. Contiguous allocation is fast to read but suffers external fragmentation and makes growth hard. Linked allocation removes fragmentation but makes random access linear. Indexed allocation, which inodes use, keeps a block of pointers per file, giving direct access with a modest indirection cost.
Journaling exists because a crash mid-update can leave the file system inconsistent. Writing the intended change to a log first means recovery can replay or discard it, turning a long consistency check into a short log scan.
File systems interview questions
- What does an inode contain — and what does it not?
- Contains: size, permissions, owner, timestamps, link count and pointers to data blocks. Does not contain: the filename. Names live in directory entries mapping name to inode number.
- Why they ask: The 'not the name' half is the point, and it explains hard links.
- What's the difference between a hard link and a symbolic link?
- A hard link is another directory entry pointing at the same inode, so both names are equal and the data survives while any link remains. A symlink is a file containing a path; deleting the target leaves it dangling. Hard links can't cross file systems or normally point to directories.
- What are the trade-offs of contiguous allocation?
- Excellent sequential and random read performance and simple bookkeeping, but external fragmentation and the need to know a file's final size in advance, since growth may require relocation.
- Why is linked allocation bad for random access?
- Each block points to the next, so reaching block n means traversing n blocks. It removes external fragmentation and grows freely, but random access is linear and one corrupt pointer loses the tail of the file.
- How does indexed allocation work, and how do inodes scale it?
- Each file gets an index block of pointers to its data blocks, so any block is reachable directly. Inodes hold some direct pointers plus single, double and triple indirect blocks, so small files stay cheap while large ones remain addressable.
- What problem does journaling solve?
- Crash inconsistency. Writing the intended change to a log before applying it means recovery replays committed entries and discards incomplete ones, replacing a full consistency scan with a short log replay.
- What's the difference between journaling metadata and journaling data?
- Metadata-only journaling protects structure but can leave file contents stale or garbled after a crash. Full data journaling protects contents too, at roughly double the write cost since data is written twice.
- What is a file descriptor?
- A small integer indexing a per-process table of open files. Entries point into a system-wide open-file table holding the offset and mode, which then references the inode — which is why two descriptors can share an offset after a fork.
- What is the page cache?
- Kernel memory caching file blocks, so repeat reads avoid the disk and writes can be batched. It's why a second read of a file is dramatically faster, and why writes need fsync to be durable.
- What happens if you delete a file another process still has open?
- The directory entry is removed so the name disappears, but the inode survives while the link count plus open descriptors is non-zero. The space is reclaimed only when the last descriptor closes.
You'll forget most of this by next week
That's not a discipline problem, it's how memory works. In the app these come back on an expanding schedule — right before you'd lose them.
Start free for 7 days