"Rafael Martinez, Guerrero" <r.m.guerrero@xxxxxxxxxxx> 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
