From owner-freebsd-fs@FreeBSD.ORG Sat Apr 13 12:42:01 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5116E59A for ; Sat, 13 Apr 2013 12:42:01 +0000 (UTC) (envelope-from paulz@vanderzwan.org) Received: from cpsmtpb-ews10.kpnxchange.com (cpsmtpb-ews10.kpnxchange.com [213.75.39.15]) by mx1.freebsd.org (Postfix) with ESMTP id B96D223F for ; Sat, 13 Apr 2013 12:42:00 +0000 (UTC) Received: from cpsps-ews03.kpnxchange.com ([10.94.84.170]) by cpsmtpb-ews10.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 13 Apr 2013 14:41:57 +0200 Received: from CPSMTPM-TLF104.kpnxchange.com ([195.121.3.7]) by cpsps-ews03.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 13 Apr 2013 14:41:56 +0200 Received: from mailvm.vanderzwan.org ([77.172.189.82]) by CPSMTPM-TLF104.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Sat, 13 Apr 2013 14:41:56 +0200 Received: from [IPv6:2001:1af8:fefb::12dd:b1ff:feb3:1119] ([IPv6:2001:1af8:fefb:0:12dd:b1ff:feb3:1119]) (authenticated bits=0) by mailvm.vanderzwan.org (8.14.6/8.14.6) with ESMTP id r3DCfooj008436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 13 Apr 2013 14:41:55 +0200 (CEST) (envelope-from paulz@vanderzwan.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: FreeBSD 9.1 NFSv4 client attribute cache not caching ? From: Paul van der Zwan In-Reply-To: <15B91473-99F4-4B48-BC18-D47B3037E8DF@vanderzwan.org> Date: Sat, 13 Apr 2013 14:41:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <495AEA10-9B8F-4A03-B706-79BF43539482@vanderzwan.org> References: <15B91473-99F4-4B48-BC18-D47B3037E8DF@vanderzwan.org> To: freebsd-fs@freebsd.org X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.9 (mailvm.vanderzwan.org [IPv6:2001:1af8:fefb::25]); Sat, 13 Apr 2013 14:41:55 +0200 (CEST) X-OriginalArrivalTime: 13 Apr 2013 12:41:56.0526 (UTC) FILETIME=[487AC4E0:01CE3844] X-RcptDomain: freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 12:42:01 -0000 On 12 Apr 2013, at 16:28 , Paul van der Zwan = wrote: >=20 > I am running a few VirtualBox VMs with 9.1 on my OpenIndiana server = and I noticed that make buildworld seem to take much longer=20 > when the clients mount /usr/src and /usr/obj over NFS V4 than when = they use V3. > Unfortunately I have to use V4 as a buildworld on V3 hangs the server = completely... > I noticed the number of PUTFH/GETATTR/GETFH calls in in the order of a = few thousand per second > and if I snoop the traffic I see the same filenames appear over and = over again. > It looks like the client is not caching anything at all and using a = server request everytime. > I use the default mount options: > 192.168.178.24:/data/ports on /usr/ports (nfs, nfsv4acls) > 192.168.178.24:/data/src on /usr/src (nfs, nfsv4acls) > 192.168.178.24:/data/obj on /usr/obj (nfs, nfsv4acls) >=20 >=20 I had a look with dtrace=20 $ sudo dtrace -n '::getattr:start { @[stack()]=3Dcount();}' and it seems the vast majority of the calls to getattr are from open() = and close() system calls.: kernel`newnfs_request+0x631 kernel`nfscl_request+0x75 kernel`nfsrpc_getattr+0xbe kernel`nfs_getattr+0x280 kernel`VOP_GETATTR_APV+0x74 kernel`nfs_lookup+0x3cc kernel`VOP_LOOKUP_APV+0x74 kernel`lookup+0x69e kernel`namei+0x6df kernel`kern_execve+0x47a kernel`sys_execve+0x43 kernel`amd64_syscall+0x3bf kernel`0xffffffff80784947 26 kernel`newnfs_request+0x631 kernel`nfscl_request+0x75 kernel`nfsrpc_getattr+0xbe kernel`nfs_close+0x3e9 kernel`VOP_CLOSE_APV+0x74 kernel`kern_execve+0x15c5 kernel`sys_execve+0x43 kernel`amd64_syscall+0x3bf kernel`0xffffffff80784947 26 kernel`newnfs_request+0x631 kernel`nfscl_request+0x75 kernel`nfsrpc_getattr+0xbe kernel`nfs_getattr+0x280 kernel`VOP_GETATTR_APV+0x74 kernel`nfs_lookup+0x3cc kernel`VOP_LOOKUP_APV+0x74 kernel`lookup+0x69e kernel`namei+0x6df kernel`vn_open_cred+0x330 kernel`vn_open+0x1c kernel`kern_openat+0x207 kernel`kern_open+0x19 kernel`sys_open+0x18 kernel`amd64_syscall+0x3bf kernel`0xffffffff80784947 2512 kernel`newnfs_request+0x631 kernel`nfscl_request+0x75 kernel`nfsrpc_getattr+0xbe kernel`nfs_close+0x3e9 kernel`VOP_CLOSE_APV+0x74 kernel`vn_close+0xee kernel`vn_closefile+0xff kernel`_fdrop+0x3a kernel`closef+0x332 kernel`kern_close+0x183 kernel`sys_close+0xb kernel`amd64_syscall+0x3bf kernel`0xffffffff80784947 2530 I had a look at the source of nfs_close and could not find a call to = nfsrpc_getattr, and I am wondering why close would be calling getattr = anyway. If the file is closed what do we care about it's attributes.... Paul