Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Feb 1998 01:15:19 -0500 (EST)
From:      "John W. DeBoskey" <jwd@unx.sas.com>
To:        freebsd-hackers@FreeBSD.ORG
Cc:        jwd@unx.sas.com (John W. DeBoskey)
Subject:   NFS V3 caching question (nfs_bio.c)
Message-ID:  <199802030615.AA04007@iluvatar.unx.sas.com>

next in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802030615.AA04007>