mbuf leakage with nfs/udp (was mbuf leakage with nfs/zfs?)

Rick Macklem rmacklem at uoguelph.ca
Thu Mar 4 23:31:01 UTC 2010



On Thu, 4 Mar 2010, Daniel Braniss wrote:

>
> correct. The interesting side effect, is that I can't see any negative
> issues when disabling the cash.

If the client retries a non-idempotent RPC, the server will do it
again, which can result in data corruption. This is likely to happen
infrequently, but with potentially nasty results. (The paper that
describes this was given at a late 1980s Usenix by Chet J. His name
is in a comment somewhere, I think. I won't dare to try and spell it.:-)

> seems ok, I have been running it now on a semi production server and
> it's holding up quiet nicely, the cache seems not up to expectations:
>
> store-mg-03# nfsstat -se
> Server Info:
>  Getattr   Setattr    Lookup  Readlink      Read     Write    Create    Remove
> 48176764    262687  12582599     19732   4225907   9186574    780793    818837
>   Rename      Link   Symlink     Mkdir     Rmdir   Readdir  RdirPlus    Access
>     7623       160     27753     59551     59552    118216         0   1992779
>    Mknod    Fsstat    Fsinfo  PathConf    Commit   LookupP   SetClId SetClIdCf
>        0    979005        19         0   1644267         0         0         0
>     Open  OpenAttr OpenDwnGr  OpenCfrm DelePurge   DeleRet     GetFH      Lock
>        0         0         0         0         0         0         0         0
>    LockT     LockU     Close    Verify   NVerify     PutFH  PutPubFH PutRootFH
>        0         0         0         0         0         0         0         0
>    Renew RestoreFH    SaveFH   Secinfo RelLckOwn  V4Create
>        0         0         0         0         0         0
> Server:
> Retfailed    Faults   Clients
>        0         0         0
> OpenOwner     Opens LockOwner     Locks    Delegs
>        0         0         0         0         0
> Server Cache Stats:
>   Inprog      Idem  Non-idem    Misses CacheSize   TCPPeak
>      307         0       297  80943198         0         0
>
If you are referring to the high miss rate, that is normal and to be
expected. It's the 297 Non-idempotent hits that could have caused data
corruption without the cache. When there is a hit, the RPC reply comes
from the cache, so that the RPC isn't performed again on the server.
(Some/many of these are not harmful. For example, a retried Remove
simply fails with ENOENT, but others...)

Glad to hear that the experimental server is working ok for you, rick



More information about the freebsd-fs mailing list