Re: Re: PostgreSQL over NFS?

I've heard of other people running databases on a Netapp Filer
I think this is generally ok because the netapp has a special
write cache in NVram and that's what makes it so fast.

On Fri, 9 Feb 2001, tc lewis wrote:

>
> On Fri, 9 Feb 2001, Shaw Terwilliger wrote:
> > I've been using PostgreSQL for a few years now in various projects, and
> > I've been very happy with its features and performance.
> >
> > I have a client who wants to know how PostgreSQL (7) will perform over
> > NFS.  The NFS client is Solaris, the server is a big network storage
> > appliance.  The network is probably gigabit ethernet.
> >
> > My first reaction is to tell them they're just crazy, and that's not how
> > a database is intended to work, and they should buy some fast, redundant
> > local storage.   I thought I'd ask the designers and users here so I could
> > back up my recommendations.
>
> we use mysql over nfs here.  it works fine.  the nfs server is a netapp.
> it's mounted over a gigabit ethernet crossover cable to the linux machine
> that runs mysqld.  it's unlikely that gigabit ethernet would be much of a
> bottleneck on any modern disks, plus netapp's wafl filesystem is basically
> faster than anything out there right now, so the only overhead is the
> tcp/ip (udp) layer, which probably isn't that expensive.  running it over
> a 100megabit line would probably slow things down some, but it all depends
> on how hard you're going to be pushing it.
>
> so the issue left is reliability.  i've looked over some of the replies
> already that talk about unreliability in general, async issues, and
> locking issues.  here's what you do to avoid all of that: use an nfs
> implementation that works.  we use linux 2.2.18 with mount and nfs-utils
> packages from http://nfs.sourceforge.net/.  we use nfsv3, not v2, and we
> mount the filesystem with the sync option.  problem solved.
>
> i haven't tried this with postgresql, but we actually are planning on
> switching to postgresql down the road, so hopefully it'll be ok.  heh.
>
> -tcl.
>