Workstation NFS Mounts Considered Evil

The symptom: Connections to the Firebird database on my MacBook Pro were taking 20 seconds. Every time.

It wasn't always thus.

It didn't matter which client I used: isql, Ruby, FlameRobin. It didn't matter if I connected from the local machine or a different workstation.

I tried installing various builds: Superserver, Classic, 64-bit and the experimental 32/64-bit build.

I used dtruss (that's an strace-like interface to dtrace for the Mac) on isql to see where it was hanging.

I watched CPU and memory and network usage.

Finally I installed Wireshark and started watching network traffic while connecting to the database. There it was. Every time, while waiting for the client to connect to the database, there was a flurry of mdns packets.

mdns? Multicast DNS. What Apple started calling Bonjour right after Tibco Software beat them to the Rendezvous.

Those flurry of packets were all attempting to lookup alpha.local. Alpha was the name of a CentOS test VM I occasionally ran in VMware Fusion. Evidently I was only allowed to connect to Firebird after first trying to resolve alpha.local (and timing out) a few times. I tried putting alpha.local in /etc/hosts. That lengthened connection times to a minute and a half or so.

Starting up the VM caused the name to resolve quickly and my Firebird connections to proceed at full speed. Shutting down the VM reverted connection times to 20 seconds again.

I nuked the VM from VMware. Still no dice.

Grepping around in various DNS-related files for alpha.local, I found the clue I needed. A forgotten NFS mount I had once used to edit a website on the VM using TextMate.

Disk Utility -> File -> NFS Mounts. Kill it. Dead. All better!

Firebird enumerates NFS mounts to ensure the database being attached does not reside on a network share, because NFS file locking is unreliable.

Next time I think I'll use Transmit if I must edit the site with TextMate. Otherwise I'll just use Vim.