user/forphan.c

Headers, purpose and an unused buffer

The comment states the purpose; the “recovery” is done by the kernel at boot, and test-xv6.py only checks for it. BUFSZ and buf are not used: they are left over from user/logstress.c, which has the same headers and the same two lines and was apparently the starting point.

main(): locals

s is the program’s name, for error messages. st receives the file’s metadata from fstat, so the program can print the inode number. ff is the file name.

Create the file and learn its inode number

open with O_CREATE (sys_open → create) allocates an inode with link count 1 and enters the name file0 in the current directory. The open file descriptor holds a reference to the inode (its in-memory ref count), which is what keeps the inode alive after the name is gone.

fstat (sys_fstat → filestat) fills st, including ino, the inode number printed later. The error message on line 25 prints the literal text ff instead of the file name: "ff" is passed where ff was meant.

Remove the name; the file lives on

unlink (sys_unlink) clears the directory entry and drops the inode’s link count from 1 to 0, inside one transaction, so after a crash the name is either still there or gone with the count at 0. It then calls iunlockput, but iput frees an inode only when it drops the last reference (ref == 1) and nlink == 0. The open file holds another reference, so the inode, still marked allocated on disk, survives.

The second open must fail: there is no name file0 any more. If it succeeded, unlink would not have removed the entry. (“successed” is a typo for “succeeded”.)

Announce the orphan and wait to be killed

The printed line is the signal test-xv6.py waits for (it matches on wait). The program then sleeps forever: pause(1000) (sys_pause) sleeps for 1000 clock ticks, about 100 seconds, and the loop repeats.

The process must not exit. If it did, kexit would close the file, the final iput would truncate and free the inode, and there would be no orphan left for the crash to strand. The same is true if you kill the process inside xv6 (for example, run it as forphan & and use kill): the file is freed at once and the next boot reports nothing. Only killing QEMU itself leaves the inode allocated with no links on the disk.

What failure looks like: if ireclaim did not run or missed the inode, the next boot prints no ireclaim: line, the script times out after 30 seconds and prints FAIL. The leaked inode would also be visible as a missing inode: ialloc would never hand out that inode number again.