On Wed, Mar 5, 2008 at 12:19 PM, Fletcher Mattox
<fletcher(_at_)cs(_dot_)utexas(_dot_)edu> wrote:
1. Apparently, a linux client by default mounts an NFS file system async.
That is, it mounts it async without an explicit "async" in the mount
options list. How else do I explain the observed 10x(!) decrease in
performance when I add "sync" to the options list. i.e. the throughput
dropped from 69.2 MB/sec to 7.40 MB/sec. I am shocked by this discovery.
Are there any other ways to interpret it?
You're reaching the limits of my knowledge here -- all my low-level
unix internals work dates from early-90s BSD. However, it's possible
(given that the NetApp server never supported async writes in the
first place) that adding "sync" to the mount options has *also* caused
linux to abandon most of its kernel file caching optimizations for
that filesystem. E.g., you're now getting real network reads where
before you were getting hits on the RAM cache copy of the file.
Whether it's possible to convince linux to use cached reads but
synchronous writes is something I don't know.
Or I may be pointing you down a rabbit hole.
As it stands now, my position seems to reduce to: "Which do you want,
performance or integrity?"
That dichotomy comes up a lot. You might try fiddling with the
rsize/wsize settings.
In any case, Bart, thank you so much for
pointing me in the right direction. This has been a real education for
for me.
You're very welcome.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail