Linux Overlay Filesystem development
 help / color / mirror / Atom feed
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

  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