public inbox for linux-unionfs@vger.kernel.org
 help / color / mirror / Atom feed
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>

  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