11 messages in com.perforce.perforce-userHow to move a tree to a new server?
FromSent OnAttachments
Robe...@fore.com31 Mar 1998 08:02 
Ping...@MIT.EDU31 Mar 1998 08:12 
Phil...@autologue.com31 Mar 1998 08:19 
Jeff...@uplanet.com31 Mar 1998 08:56 
Rich...@netapp.com31 Mar 1998 09:41 
Tony...@informix.com31 Mar 1998 09:53 
Rich...@netapp.com31 Mar 1998 10:03 
Tim....@westmerchant.co.ukTim.Meadowcroft31 Mar 1998 11:33 
WesP...@xmission.com31 Mar 1998 15:26 
WesP...@xmission.com31 Mar 1998 15:33 
Rich...@netapp.com31 Mar 1998 15:34 
Subject:How to move a tree to a new server?
From:Rich...@netapp.com (Rich@netapp.com)
Date:03/31/1998 09:41:29 AM
List:com.perforce.perforce-user

This is interesting. Were both the NFS server (remote machine with the RAID array) and the NFS client side (the host running p4d and NFS mounting the stuff in P4ROOT) running Solaris?

(Assuming so) Did you ever have a chance to determine whether the problems seemed to be on the NFS server or client side, or in any more detail the nature of the problem? I'm a little surprised, given what I know, that Perforce would challenge the NFS implementation particulary; on the other hand, I find it hard to believe that Sun's NFS server implementation is generally flakey, or flakey for some reason with that RAID subsystem. (Note: we compete with Sun in the NFS server space, but our advantages don't usually include "Sun NFS is flakey"!)

Being who we are, we store our P4ROOT on one of our own NetApp filers; the host running our p4d is running Solaris, so we're using their NFS client side implementation. We recently completed the conversion of all of our product source code into Perforce. No sign of corruption of any kind yet.

*** Blatent NetApp Product Plug:

Using NFS to a high-availability server for the file services Perforce depends on has some significant advantages. For one thing, it gives you some redundancy in case the host running p4d suffers a serious hardware failure, since you can just move p4d to a different host (of the same machine architecture... last I heard, you couldn't restart on a DEC alpha server with a P4ROOT/*.db created on a Solaris box) and keep on going. We run with an NIS host map entry "p4netapp" that selects the actual host running p4d; if the primary "p4netapp" host fails, we repoint the entry to a backup host, start p4d on that host, and Keep On Truckin.

You could do the same with any NFS server in place of the NetApp, but we like our own products in this role; it automatically buys you RAID protection (any single disk in the server can fail and it hums right along with no loss in service or data accessability). It also sports very good performance, and, properly configured, will perform as well or better than a locally attached RAID array. There are further advantages... but:

OK, you're right, that's enough of a Blatant NetApp Product plug. If anybody is particulary interested in using NFS for Perforce data in general, or with NetApp servers specifically, email me privately.

There's not quite enough context to tell if you're getting ready to hit a problem I ran into when I first started using Perforce, so I'll pass along the story and let you decide.

I used a RAID storage array running on a remote machine (accessed via NFS) as my Perforce database and depot. The Solaris implementation of NFS, however, is flakey enough that this is a problem - the database became corrupted pretty frequently, and I learned the virtues of enabling journaling.

Could you describe the nature of the corruption, how it was first noticable, etc?

The moral to *my* story was "don't rely on Solaris NFS for database files".

Well, as noted above *we* do (client side), and have seen zero problems.

-Jeff Bowles