Commit a74ac322 authored Mar 24, 2009 by Chris Mason

Btrfs: Make sure i_nlink doesn't hit zero too soon during log replay

During log replay, inodes are copied from the log to the main filesystem
btrees. Sometimes they have a zero link count in the log but they actually
gain links during the replay or have some in the main btree.

This patch updates the link count to be at least one after copying the
inode out of the log. This makes sure the inode is deleted during an
iput while the rest of the replay code is still working on it.

The log replay has fixup code to make sure that link counts are correct
at the end of the replay, so we could use any non-zero number here and
it would work fine.

Signed-off-by: Chris Mason <chris.mason@oracle.com>

parent a4b6e07d

fs/btrfs/tree-log.c

+11 −0

Original line number	Diff line number	Diff line
		@@ -1532,6 +1532,17 @@ static int replay_one_buffer(struct btrfs_root log, struct extent_buffer eb,
		root, inode, inode->i_size,
		BTRFS_EXTENT_DATA_KEY);
		BUG_ON(ret);

		/* if the nlink count is zero here, the iput
		* will free the inode. We bump it to make
		* sure it doesn't get freed until the link
		* count fixup is done
		*/
		if (inode->i_nlink == 0) {
		btrfs_inc_nlink(inode);
		btrfs_update_inode(wc->trans,
		root, inode);
		}
		iput(inode);
		}
		ret = link_to_fixup_dir(wc->trans, root,

Admin message