Fwd: [Question] Unlinking original file of bind mounted file.

[Yun Levi <ppbuk5246@gmail.com>]

> 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,