From owner-freebsd-fs@freebsd.org Sun Aug 28 04:27:25 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8CCAA9478B for ; Sun, 28 Aug 2016 04:27:25 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by mx1.freebsd.org (Postfix) with ESMTP id 6B892813 for ; Sun, 28 Aug 2016 04:27:24 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ppp14-2-4-72.lns21.adl2.internode.on.net (HELO leader.local) ([14.2.4.72]) by ipmail04.adl6.internode.on.net with ESMTP; 28 Aug 2016 13:57:18 +0930 Subject: Re: [ZFS] ARC accounting bug ? To: Ben RUBSON , FreeBSD FS References: <71DED907-10BE-44C2-982B-12974152895D@gmail.com> From: Shane Ambler Message-ID: <16ca6964-4d10-e4b0-7d9f-c1da5a95f5ac@ShaneWare.Biz> Date: Sun, 28 Aug 2016 13:57:16 +0930 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <71DED907-10BE-44C2-982B-12974152895D@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 04:27:25 -0000 On 28/08/2016 01:45, Ben RUBSON wrote: > >> On 27 Aug 2016, at 07:22, Shane Ambler 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