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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
