Reading An Empty Inode

Here is the I/O trace for create(/foo/bar) on a vsfs-style file system, cold cache:

#	structure	op
1	root inode	read
2	root data	read
3	`foo` inode	read
4	`foo` data	read
5	inode bitmap	read
6	inode bitmap	write
7	`foo` data	write
8	`bar` inode	read
9	`bar` inode	write
10	`foo` inode	write

Step 8 reads bar's inode before step 9 initializes it, even though that inode has never held anything and the file system is about to overwrite every field. Why is the read there?

It reads back the directory entry written in step 7, to recover the i-number the allocator assigned.

An inode is far smaller than a block (256 bytes inside a 4 KB block), so the block holds roughly 15 other live inodes. The file system cannot write one inode; it must read the block, modify 256 bytes, and write the whole block back.

It re-reads the inode bitmap slot indirectly, to confirm no concurrent create() claimed the same i-number between steps 5 and 6.

It fetches the inode's generation counter, which must be incremented rather than reset so that stale NFS file handles pointing at the old file cannot alias the new one.