This is an always reproduced case for NFSv3 over overlayfs, and each
dir under nfs mount point behaviors the same. The same overlay
exported mount with NFSv4 returns correct d_type. And for ext4
exported mount with NFSv3 returns correct as well.
My simple test program is like:
void main(int argc, void **argv) {
DIR *dir = opendir(argv[1]);
if (dir == NULL) {
fprintf(stderr,
"ERROR: Could not open dir: %s\n", argv[1]);
return;
}
struct dirent *ent;
while ((ent = readdir(dir)) != NULL) {
printf("readdir: %s ino(%x) type(%x)\n", ent->d_name,
ent->d_ino, ent->d_type);
}
closedir(dir);
}
output is:
readdir: . ino(e0003) type(0)
readdir: .. ino(e0003) type(0)
readdir: foo ino(e0007) type(0)
2018-03-14 23:14 GMT+08:00 Amir Goldstein <amir73il@xxxxxxxxx>:
> On Wed, Mar 14, 2018 at 5:06 PM, Trond Myklebust
> <trondmy@xxxxxxxxxxxxxxx> wrote:
>> On Wed, 2018-03-14 at 17:03 +0200, Amir Goldstein wrote:
>>> On Wed, Mar 14, 2018 at 4:30 PM, Jeff Layton <jlayton@xxxxxxxxxx>
>>> wrote:
>>> > On Wed, 2018-03-14 at 14:16 +0000, Trond Myklebust wrote:
>>> > > On Wed, 2018-03-14 at 07:02 -0400, Jeff Layton wrote:
>>> > > > 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.
>>> > > >
>>> > >
>>> > > Yes, but one of the main such applications is the "find" utility,
>>> > > which
>>> > > uses it to avoid calling stat() in order to discover the
>>> > > directories.
>>> > > For that reason, NFS does try to set the d_type flag when it is
>>> > > using
>>> > > readdirplus, and the server returns attributes for the entry in
>>> > > question. Otherwise, it is forced to default to DT_UNKNOWN.
>>> > >
>>> >
>>> > Yes, didn't mean to imply that we shouldn't try to fill these out
>>> > where
>>> > we can, just that there are situations where we might not be able
>>> > to do
>>> > so without taking a performance hit.
>>> >
>>> > > Note that in the cases where the readdir entry has a matching
>>> > > dentry,
>>> > > we probably could try to do better by doing a d_lookup() and then
>>> > > filling the d_type. Is that worth doing?
>>> > >
>>> >
>>> > I like that idea. Filling out what info we can from the local cache
>>> > is
>>> > almost always worthwhile.
>>> >
>>> > An inode's d_type can never change, so you can just vet the fileid
>>> > or fh
>>> > in the entry3 vs. the inode that comes back from d_lookup. If they
>>> > match
>>> > then you can reliably fill that out.
>>> >
>>>
>>> Ironically, this is where NFS over overlayfs may fail, because in
>>> overlayfs
>>> d_ino is not always consistent with st_ino. Since v4.15, d_ino is
>>> consistent
>>> with st_ino for the case of all layers on the same filesystem. I
>>> already posted
>>> a POC for fixing d_ino/st_ino for non-samefs, but it never got
>>> merged.
>>>
>>> What puzzles me w.r.t. this "nonbug" report is that I don't
>>> understand why
>>> NFS over overlayfs would behave differently vs. NFS over local fs.
>>> I am hoping it does not point to a different problem, so would love
>>> to
>>> get a more detailed analysis of what's going on between nfsd and
>>> overlayfs.
>>
>> The behaviour being described is true of the regular NFS client. It has
>> nothing to do with overlayfs.
>>
>
> Here:
> https://marc.info/?l=linux-unionfs&m=152093050204357&w=2
>
> Eddie claims that the observed DT_UNKNOWN issue is reproduced
> with NFSv3 over overlayfs and NOT with NFSv3 over ext4.
>
> That's the only fact I find puzzling.
>
> But I did not see a confirmation that this is a reproducible problem
> with exact same directory and I did not try to reproduce it myself.
>
> 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
