On Mon, 2006-05-22 at 10:25, Greg Stark wrote:
> 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.
>
Well, having a protocol that by definition says that datagrams may
arrive out of order or go missing without notice does not sound like a
good thing to have a database running on.
[.......]
> environment. But the others shouldn't be terribly relevant -- hell, bg only
> affects the actual mount operation.
>
The result of using cut & paste ;) not directly relevant to postgres but
nice to have when mounting the nfs directory.
> 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?
>
Samba? :-) not at all, it was a way of saying how bad idea is to run a
database via NFS if you want reliability and performance. Not everybody
agrees with this, but well, they can do what the want with their data.
>
> "async" "intr" and "soft" seem like the real foot-guns here.
Why do you think 'intr' is a bad thing, from man pages:
" ........ If an NFS file operation has a major timeout and it is
hard mounted, then allow signals to interupt the file operation and
cause it to return EINTR to the calling program. The default is to not
allow file operations to be interrupted ....."
This will be like an error reported by the filesystem, the program will
get the information and will take care of the problem instead of waiting
indefinitely for a respons not comming and having the database probably
in a nonconsistent state.
With 'noac' I was thinking about two processes trying to access the same
file at the same time, better not to have some cache in our way that
alter the real state of the file to other processes.
--
Rafael Martinez, <r.m.guerrero@usit.uio.no>
Center for Information Technology Services
University of Oslo, Norway
PGP Public Key: http://folk.uio.no/rafael/
