Adobe·Software Engineer·Technical Phone Screen·Senior

Senior

May 2026

Summary

Adobe systems design phone screen, pretty deep Linux internals question that honestly felt more like an OS course exam than a typical SWE interview. One question, lots of sub-parts, and I was scrambling to remember things I hadn't touched since college.

Questions Asked (1)

A script in one terminal continuously writes to log.txt. A second terminal is running `tail -f log.txt`. A third terminal runs `rm log.txt`. Walk through what happens to: the writer's file descriptor and ongoing writes, what the tailer sees, what happens to the directory entry and the inode, and when disk space actually gets reclaimed. Also explain how `lsof | grep deleted` exposes this situation, and touch on the discrepancy you'd see between `df` and `du` after such a delete.

System DesignTechnical Trade-offsRoot Cause Analysis

Author's notes

I knew the broad strokes.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Walk through the scenario step by step, focusing on the distinction between the directory entry and the inode, and how open file descriptors keep the inode alive. Explain the behavior of each process (writer, tailer, rm) and the implications for disk space and system tools. Conclude with how lsof and the df/du discrepancy reveal the underlying mechanics.

Pro tip: Emphasize that the file is not truly deleted until all open file descriptors are closed, and mention that this is a common cause of disk space leaks in production. Suggest using lsof +L1 to quickly identify such files.

1. Understand the initial state

Before rm, log.txt has a directory entry pointing to an inode. The writer has an open file descriptor (fd) to the inode, and tail -f also has an open fd. The inode's link count is 1 (from the directory entry).

2. Analyze the effect of rm

rm removes the directory entry for log.txt, decrementing the inode's link count to 0. However, because the writer and tailer still hold open file descriptors, the inode is not deallocated. The file data remains on disk.

3. Describe writer and tailer behavior

The writer continues writing to the same inode via its fd; the data is appended to the file. The tailer, still reading from the same inode, continues to see new lines as they are written. Neither process is aware of the deletion.

4. Explain disk space reclamation

Disk space is not reclaimed until all open file descriptors to the inode are closed. When the writer and tailer terminate (or close their fds), the inode's reference count drops to zero, and the file system frees the data blocks.

5. Discuss lsof and df/du discrepancy

lsof | grep deleted shows the file as deleted but still open by processes. df reports the file system as full because the blocks are still allocated, while du does not count the file because it has no directory entry, leading to a discrepancy.

Key Points to Mention

Directory entry vs. inode: rm removes the directory entry, but the inode persists while open file descriptors exist.
Open file descriptors keep the inode alive; the file is not truly deleted until all fds are closed.
Writer and tailer continue unaffected because they operate on the inode, not the directory entry.
Disk space is reclaimed only after the last file descriptor is closed.
lsof | grep deleted (or lsof +L1) identifies files that are deleted but still held open, explaining the disk usage.
df shows used blocks because the inode still holds them, while du does not see the file due to missing directory entry, causing a discrepancy.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.