[zfs-discuss] Unlistable files

Vladimir Brik vladimir.brik at icecube.wisc.edu
Fri Apr 6 12:59:20 EDT 2018


> If the strace output does not show telldir() and seekdir() (or maybe just
> seek(fd, SEEK_CUR, 0) on the directory), then that is not the issue.
Strings "telldir", "seekdir", and "seek" do not appear in the output of
strace.

Vlad

On 04/05/2018 10:21 PM, Andreas Dilger wrote:
> On Apr 5, 2018, at 17:40, Gionatan Danti <g.danti at assyoma.it> wrote:
>>
>> Il 05-04-2018 23:58 Andreas Dilger via zfs-discuss ha scritto:
>>> It might also be that "ls" and ZFS directory iteration do not play well
>>> together, skipping some entries in the directory (e.g. hash collisions,
>>> or if telldir() and seekdir() do not work properly).  If your problem
>>> only happens on large directories then this is a possibility.
>>
>> Can you expand on that point? It would be quite concerning if basic call as telldir() and seekdir() do not work properly.
> 
> Well, *something* isn't working properly, it just isn't clear what that is. 
> 
> If the strace output does not show telldir() and seekdir() (or maybe just
> seek(fd, SEEK_CUR, 0) on the directory), then that is not the issue. 
> 
>> How about the hash collision possibility? Are we speaking about the collision of *which* specific element (metadata, filename, etc)?
> 
> This can be an issue if telldir() returns a cookie to userspace, but the cookie
> is not unique, then seekdir() finds the wrong entry to restart. There is logic
> in ZFS to disambiguate non-unique cookies, but that could be broken. 
> 
> If the problem is easily reproduced, and did not exist in earlier releases,
> then using "git bisect" to find the patch that added the problem is also
> possible, if the problem is only with the directory iteration and is not a
> bug in how the entry was inserted into the directory. 
> 
> Cheers, Andreas
> 


More information about the zfs-discuss mailing list