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
