"Rafael Martinez, Guerrero" <r.m.guerrero@usit.uio.no> writes:
> I would say that anything is better than NFS for running a database. But
> if you absolutely have to use NFS, run NFS via TCP not UDP, use hard and
> turn off all cache ..... In the server side we are talking about 'sync'
> and 'no_wdelay' parameters and in the client about
> 'bg','hard','intr','noac' and 'tcp', probably the throughput will
> improve by increasing rsize and wsize to 16384 or even 32768.
Using TCP with NFS is only really helpful when you have a high latency high
bandwidth link which isn't going to be a terribly positive environment for
postgres.
I'm not sure about all your other recommendations either, they strike me as a
bit cargo-cultish. Certainly not mounting your filesystem soft will protect
against unknowingly losing data if your server crashes, and boosting wsize and
rsize will help though the optimal values will depend on your specific
environment. But the others shouldn't be terribly relevant -- hell, bg only
affects the actual mount operation.
While I'm leery about recommending any network filesystem for anything that
depends on the filesystem as heavily as a database, of all the network
filesystems NFS takes the most care to maintain solid semantics. The main
problem is that people are always looking for new and interesting ways to
defeat those semantics with options like soft mounts. Certainly I can't agree
with "anything is better than NFS", what would you recommend, samba?
Now that I've read up on what "async" does it seems like the errors are a
pretty predictable consequence. Making directory operations asynchronous is
going to break a LOT of things. Most Unix mail servers, for example, also
depend on directory operations being synchronous. I would expect "async" to
cause Postgres errors on any filesystem that supports it.
"async" "intr" and "soft" seem like the real foot-guns here.
--
greg