> No, that's not correct. Here's how to think about Unix files (not just
> ext4, going all the way back to the 1970s). Each inode has a reference
> count. All kinds of things hold a reference count to an inode; some of
> the more common ones are a name in a directory, an open file, a mmap of
> that open file, passing a file descriptor through a unix socket, etc, etc.
>
> Unlink removes a name from a directory. That causes the reference count
> to be decreased, but the inode will only be released if that causes the
> reference count to drop to 0. If the file is open, or it has multiple
> names, it won't be removed.
>
> mount --bind obviously isn't traditional Unix, but it fits in the same
> paradigm. It causes a new reference count to be taken on the inode.
> So you can remove the original name that was used to create the link,
> and that causes i_nlink to drop to 0, but the in-memory refcount is
> still positive, so the inode will not be reused.
>
Actually, when the bind mount happens on the some file, it doesn't
increase the inode->i_count,
Instead of that, it increases dentry's refcount.
So, If we do "mount --bind a b"
it just increases the reference of dentry of a, not i_count of a.
So, when rm -f a, it just put the reference of dentry, but not
decreased the reference count of inode->i_count.
When the unlink on b, finally the dentry is killed and free the inode.
That's the reason why inode's count sustains "1" though a was unlinked
but makes the inode->n_link as 0.
Here is What I saw via crash the b's inode's reference count which
after unlink the original a.
// 0xffff0000c6af9d18 is the inode which unlinks the original file.
(mentioned as b above).
crash> struct inode.i_count 0xffff0000c6af9d18
i_count = {
counter = 1
},
crash> struct inode.i_nlink 0xffff0000c6af9d18
i_nlink = 0,
