[ZFS] ARC accounting bug ?

[Shane Ambler]

On 28/08/2016 01:45, Ben RUBSON wrote:
>
>> On 27 Aug 2016, at 07:22, Shane Ambler <FreeBSD at ShaneWare.Biz> wrote:
>>
>> On 26/08/2016 19:09, Ben RUBSON wrote:
>>> Hello,
>>>
>>> Before opening a bug report, I would like to know whether what I see
>>> is "normal" or not, and why.

>> What I am seeing leads me to think that not all metadata is cached,
>> maybe filename isn't cached, which can be a large string.
>>
>> while [ 1 ]; do find /usr/ports > /dev/null; done
>>
>> will list the path to every file and I see about 2 hits to a miss, yet
>>
>> while [ 1 ]; do ls -lR /usr/ports > /dev/null; done
>>
>> lists every filename as well as it's size, mod date, owner, permissions
>> and it sits closer to 4 hits to every miss.
>>
>> And if the system disk cache contains the filenames that zfs isn't
>> caching we won't need disk access to get the zfs misses.
>
> Playing with these commands :
> # dtrace -n 'sdt:zfs::arc-hit {@[execname, stack()] = count();}'
> # dtrace -n 'sdt:zfs::arc-miss {@[execname, stack()] = count();}'
>
> We can see that these are readdir calls which produce arc-misses,
> andthat readdir calls also produce arc-hits.
>
> It would be interesting to know why some lead to hits, and some lead
 > to misses.
>
> (note that ls -lR / rsync commands produces exactly the same dtrace
 > results/numbers as find command)

ls outputs the filename - find outputs the full path, could tracing
back through parent folders get the extra misses.

-- 
FreeBSD - the place to B...Software Developing

Shane Ambler