On Wed, Mar 14, 2018 at 10:42 AM, Eddie Horng <eddiehorng.tw@xxxxxxxxx> 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 Can you provide a simple reproducer? Is DT_UNKNOWN always the case in readdir or only in lower/upper/merged directories? for all entries? > 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? > Thanks for the detailed analysis. Seems like server side sets the post op attr in encode_post_op_attr() probably from nfs3svc_encode_readdirres(). There is a comment above encode_post_op_attr() that I don't fully understand and not sure why that would happen in overlayfs. If you can perform similar tracing on server side and point us at where the overlay and non-overlay flows diverge this would be helpful. I also recommend testing with v4.16-rc5, which has some overlayfs NFS export fixes, although, I am not sure how any of those fixes map to the problem you reported and I didn't have time to test your report myself yet. Thanks, Amir. -- 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
