From: Jeff Layton <jlayton@kernel.org>
To: Eddie Horng <eddiehorng.tw@gmail.com>
Cc: Amir Goldstein <amir73il@gmail.com>,
Miklos Szeredi <miklos@szeredi.hu>,
overlayfs <linux-unionfs@vger.kernel.org>,
Trond Myklebust <trondmy@primarydata.com>,
"J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: readdir returns d_type=DT_UNKNOWN to overlay exported dir (NFSv3)
Date: Wed, 14 Mar 2018 07:02:57 -0400 [thread overview]
Message-ID: <1521025377.4552.6.camel@kernel.org> (raw)
In-Reply-To: <CALLuPvpczs-UiDkoHURAu7weCHJCv9U6xKxDKck=5U85T55ukw@mail.gmail.com>
On Wed, 2018-03-14 at 16:42 +0800, Eddie Horng wrote:
> Hi Amir,
> Since the flock issue is clarified, I would like to start this new
> thread to discuss if we can find the cause of d_type=DT_UNKNOWN. First
This sounds like NOTABUG to me. As readdir(3) states:
Currently, only some filesystems (among them: Btrfs, ext2, ext3,
and ext4) have full support for returning the file type in
d_type. All applications must properly handle a return of
DT_UNKNOWN.
Applications that rely solely on d_type are effectively broken. You
always need to be able to follow up with a stat or equivalent.
> of all I tried rdirplus and nordirplus mount option but got no
> difference. Then I roughly trace call flow of nfs3_decode_dirent( ) as
> below:
>
> decode_fattr3()
> fattr->mode = (be32_to_cpup(p++) & ~S_IFMT) | fmode;
> fattr->valid |= NFS_ATTR_FATTR_V3;
>
> decode_post_op_attr()
> p = xdr_inline_decode(xdr, 4);
> if (*p != xdr_zero)
> return decode_fattr3(xdr, fattr);
>
> nfs3_decode_dirent()
> entry->d_type = DT_UNKNOWN;
> if (entry->fattr->valid & NFS_ATTR_FATTR_V3)
> entry->d_type = nfs_umode_to_dtype(entry->fattr->mode);
>
> In overlay exported case, decode_post_op_attr hits *p==xdr_zero, so
> decode_fattr3 is not called, then d_type reamins DT_UNKNOWN in
> nfs3_decode_dirent. It seems nfs4_decode_dirent has very different way
> to decode file attr and maybe the xdr layout is quite different as
> well.I have not idea about how the xdr to be filled from overlay and
> nfsd's output. Could some of you master give a hint?
Very different.
The v3 client will sometimes issue a READDIR (just names and fileids of
dirents) and sometimes a READDIRPLUS (same as READDIR + attributes)
depending on the expected size of the result and what sort of access
pattern the application has. If you get back DT_UNKNOWN, it's quite
possible that it chose to use a READDIR and therefore doesn't have
enough info to fill out the d_type.
Cheers,
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2018-03-14 11:02 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-14 8:42 readdir returns d_type=DT_UNKNOWN to overlay exported dir (NFSv3) Eddie Horng
2018-03-14 9:56 ` Amir Goldstein
2018-03-14 11:02 ` Jeff Layton [this message]
2018-03-14 14:16 ` Trond Myklebust
2018-03-14 14:30 ` Jeff Layton
2018-03-14 15:03 ` Amir Goldstein
2018-03-14 15:06 ` Trond Myklebust
2018-03-14 15:14 ` Amir Goldstein
2018-03-14 15:40 ` Eddie Horng
2018-03-15 9:23 ` Eddie Horng
2018-03-15 9:47 ` Eddie Horng
2018-03-15 13:13 ` Amir Goldstein
2018-03-15 13:22 ` Trond Myklebust
2018-03-15 14:30 ` Eddie Horng
2018-03-15 18:40 ` Amir Goldstein
2018-03-15 21:48 ` Amir Goldstein
2018-03-16 6:25 ` Eddie Horng
2018-03-16 7:23 ` Amir Goldstein
2018-03-16 8:06 ` Eddie Horng
2018-03-16 9:50 ` Amir Goldstein
2018-03-16 15:06 ` Eddie Horng
2018-03-16 15:28 ` Amir Goldstein
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=1521025377.4552.6.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=amir73il@gmail.com \
--cc=bfields@fieldses.org \
--cc=eddiehorng.tw@gmail.com \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=trondmy@primarydata.com \
/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