From: Xu Wang <xuw@redhat.com>
To: hujianyang <hujianyang@huawei.com>, Atom2 <ariel.atom2@web2web.at>
Cc: linux-unionfs@vger.kernel.org, Miklos Szeredi <miklos@szeredi.hu>
Subject: Re: stat inconsistency with overlayfs
Date: Thu, 26 Feb 2015 01:45:37 -0500 (EST) [thread overview]
Message-ID: <37851744.28042779.1424933137550.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <54EEAE3A.5000006@huawei.com>
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.
Thanks,
George
--
George Wang 王旭
Kernel Quantity Engineer
Red Hat Software (Beijing) Co.,Ltd
IRC:xuw
Tel:+86-010-62608041
Phone:15901231579
9/F, Tower C, Raycom
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-02-26 6:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-20 18:15 stat inconsistency with overlayfs Atom2
2015-02-26 5:25 ` hujianyang
2015-02-26 6:45 ` Xu Wang [this message]
2015-03-02 20:45 ` Atom2
2015-03-03 15:14 ` Miklos Szeredi
2015-03-03 17:12 ` Atom2
2015-03-04 2:24 ` hujianyang
2015-03-04 11:06 ` Miklos Szeredi
2015-03-02 20:45 ` Atom2
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=37851744.28042779.1424933137550.JavaMail.zimbra@redhat.com \
--to=xuw@redhat.com \
--cc=ariel.atom2@web2web.at \
--cc=hujianyang@huawei.com \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox