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
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
