Re: stat inconsistency with overlayfs

[Atom2 <ariel.atom2@web2web.at>]

Hi Xu,
thanks for your follow-up.
Am 26.02.15 um 07:45 schrieb Xu Wang:
> Hi, Hu, Atom2,
>
>> I don't have the Overlayfs code on 3.11 or 3.13. I've lookup the v11
>> code in Miklos's git tree:
> Fortunately I got the overlay fs code of kernel V3.18, which is mostly
> same to v11 code in Miklos's git.
>
> 135 static int ovl_dir_getattr(struct vfsmount *mnt, struct dentry *dentry,
> 136              struct kstat *stat)
> 137 {
> 138     int err;
> 139     enum ovl_path_type type;
> 140     struct path realpath;
> 141
> 142     type = ovl_path_real(dentry, &realpath);
> 143     err = vfs_getattr(&realpath, stat);
> 144     if (err)
> 145         return err;
> 146
> 147     stat->dev = dentry->d_sb->s_dev;
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ here set dev number as Hu mentioned
> 148     stat->ino = dentry->d_inode->i_ino;
> 149
> 150     /*
> 151      * It's probably not worth it to count subdirs to get the
> 152      * correct link count.  nlink=1 seems to pacify 'find' and
> 153      * other utilities.
> 154      */
> 155     if (type == OVL_PATH_MERGE)
> 156         stat->nlink = 1;
> 157
> 158     return 0;
> 159 }
>
> And the d_sb->s_dev is coming from the super_block of overlayfs, which is fake.
> The super block s_dev is initialized by the call trace
> "mount_nodev->set_anon_super-->get_anon_bdev".
>
> Either the dir exists in lower or exists in upper, the overlay fs fakes it exits in
> overlay, which holds the fake device number.
I see what you are saying and code-wise that seems to be the cause of 
the behaviour I am seeing. I am, however, still not convinced at all 
that this is the correct/to be expected behaviour.

Giving this some further thought, might this not create more issues 
further down the line: In my (granted: limited) understanding the 
device/i-number combination must be unique across all mounted 
file-systems. Now does this also mean that the i-number is faked as 
well? In other words what is going to happen if the i-number of the 
directory residing in the upperdir (but wrongly attributed to the 
lowerdir) is identical to an i-number of another existing entry in the 
lowerdir?

Finally, stat, as I understand it, amongst other pieces of information 
also provides information about the device an entry resides on and that 
information, IMHO, simply is plain wrong for directories only existing 
on the upperdir.

Thanks Atom2