lk: drop parent's nlink during directory unlink

[Zach Brown]

> Can you give this patch a think?

Yeah.  Thanks for looking in to this.

> Basically, we weren't dropping nlink in our parent directory
> during the 'rmdir bar'.

*nod*

> This patch fixes the issue.

Well, it gets the accounting for '..' right so that removed dirs don't
pin their parents.  I think it still needs to worry about '.' so that we
eventually get ->delete_inode called for the removed dir once the last
user closes it.

> My doubt comes from, should we be
> doing a simple drop_nlink() on our parent directory, or should we
> be expressing that as a change?

It's fine to modify the vfs structure and then use the change func to
update the dirty crfs item in the metadata cache from the vfs structure.
 crfs_change_cinode() does this for the parent inode when
crfs_meta_change_commit() is called, and it updates nlink, so yeah, that
part of the patch is fine.

> +	if (S_ISDIR(inode->i_mode))
> +		drop_nlink(dir);

I think we also want a drop_nlink(inode) for "." when the inode is a
directory, too.  And once we have those you might as well drop the stale
comment about them on the next line down :).

It's a little weird that we're not removing the actual . and .. items
when we drop the nlink.  This works out because we drop all the items
for the dir's objectid when we get to ->delete_inode.  And we want "cd
.." to work from a deleted directory, so today we arguably want to keep
them around even though nlink is 0 in the removed dir.

This will last bit will be less confusing when we move to a more modern
BTRFS format which doesn't have expliclt '.' and '..' entries.

- z