From owner-freebsd-hackers Mon Feb 2 22:15:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA00735 for hackers-outgoing; Mon, 2 Feb 1998 22:15:29 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from lamb.sas.com (root@lamb.sas.com [192.35.83.8]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA00728 for ; Mon, 2 Feb 1998 22:15:26 -0800 (PST) (envelope-from jwd@unx.sas.com) Received: from mozart (markham.southpeak.com [192.58.185.8]) by lamb.sas.com (8.8.7/8.8.7) with SMTP id BAA03841 for ; Tue, 3 Feb 1998 01:15:20 -0500 (EST) Received: from iluvatar.unx.sas.com by mozart (5.65c/SAS/Domains/5-6-90) id AA07430; Tue, 3 Feb 1998 01:15:20 -0500 From: "John W. DeBoskey" Received: by iluvatar.unx.sas.com (5.65c/SAS/Generic 9.01/3-26-93) id AA04007; Tue, 3 Feb 1998 01:15:19 -0500 Message-Id: <199802030615.AA04007@iluvatar.unx.sas.com> Subject: NFS V3 caching question (nfs_bio.c) To: freebsd-hackers@FreeBSD.ORG Date: Tue, 3 Feb 1998 01:15:19 -0500 (EST) Cc: jwd@unx.sas.com (John W. DeBoskey) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe hackers" Hello, I am attempting to figure out why nfs v3 caching doesn't seem to be giving me the performance boost I'm looking for. One of the items I've discovered is that the tail end (or lack thereof for even blksize multiple files) of a file doesn't seem to be cached. In a shell script, I am repeatedly cat'ing an an 8k file which I would expect to be cached. (Yes, I am talking nfs v3 to a network appliance F540). cd /net/netapp/home/jwd for i in 1 2 3 4 etc; do cat base/h/8k.h > /dev/null nfsstat | while read line; do ... collect & output stats ... done done Between each cat, as seen above, I call 'nfsstat' and gather the Attr & BioR Hit/Miss numbers. The output follows: Attr Hits Misses Pct BioR Hits Misses Pct 204 43 21 12 27 225 221 46 20 13 29 223 238 49 20 14 31 221 255 52 20 15 33 220 272 55 20 16 35 218 289 58 20 17 37 217 306 61 19 18 39 216 323 64 19 19 41 215 340 67 19 20 43 215 357 70 19 21 45 214 374 73 19 22 47 213 391 76 19 23 49 213 ^^ ^^ 3 attr misses? 2 cache misses? I added a couple of printf() statements to nfs_bioread() in nfs_bio.c to help understand why I'm seeing the Misses. nfs_bio.c: offset 0 not in cache! bp->b_blkno==0 nfs_bio.c: offset 0 was in cache! bp->b_blkno==1 nfs_bio.c: offset 8192 not in cache! bp->b_blkno==1 nfs_bio.c: offset 8192 was in cache! bp->b_blkno==1 nfs_bio.c: offset 8192 not in cache! bp->b_blkno==1 nfs_bio.c: offset 8192 was in cache! bp->b_blkno==1 nfs_bio.c: offset 0 was in cache! bp->b_blkno==0 nfs_bio.c: offset 8192 not in cache! bp->b_blkno==1 nfs_bio.c: offset 8192 was in cache! bp->b_blkno==1 nfs_bio.c: offset 8192 not in cache! bp->b_blkno==1 nfs_bio.c: offset 8192 was in cache! bp->b_blkno==1 Well, offset 0 for 8k appears to be cached correctly. I do not understand (yet, I'm working on it) why we are even attempting to read bp->b_blkno==1 since it doesn't exist. Yes, the file is 8k. -rw-r--r-- 1 jwd jwd 8192 Feb 2 20:47 /net/netapp/home/jwd/8k.h Any comments (helpful) or critiques (telling me I'm looking in the wrong place) are welcome. Thanks, John ps: If the file size is 8193, then block numbers 0 & 1 are always cached, but the last block, 2, for 1 byte length, is never found in the cache. pss: I almost think I'm looking for a bad length comparison. -- jwd@unx.sas.com (w) John W. De Boskey (919) 677-8000 x6915