Re: readdir returns d_type=DT_UNKNOWN to overlay exported dir (NFSv3)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux