NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
I'm running v3 here on Mesonet. We do some "interesting" cross-mounts without problems.
gerry Robert Mullenax wrote:
Under RH 6.2, we would have to specify NFS version 2, but this version of RH supports version 3. I would maybe look at NFS versions to see which version each box is running. As an aside, based on a lot of NFS use here.. I will say that you will be much happier in the long runif you just ran Solaris x86 instead of RH 9. NFS was and continues to be a problem on Linux. You will never getthe same NFS performance with a Linux NFS server as you would with a Solaris box (SPARC or x86). Robert -----Original Message----- From: Patrick O'Reilly [mailto:patrick.oreilly@xxxxxxx] Sent: Friday, November 14, 2003 12:29 PM To: ldm-users@xxxxxxxxxxxxxxxx; gembud@xxxxxxxxxxxxxxxx Subject: LDM/GEMPAK NFS Question Hello, I am switching my LDM machine from a Sun Solaris 8 machine to a PC running RedHat 9. This PC will feed the data via NFS to 4 Sun Solaris 8 machines, who in turn run GEMPAK scripts on the data and post imagery to the web. My prior setup had the 4 Suns mounting the NFS share of another Sun and things went well. I just made the switchover, i.e. made the PC/Redhat machine the NFS server to the 4 Suns, and the mount went fine. The problem is, now the GEMPAK scripts take a very long time to run on the Suns. A simple script takes a couple minutes where it used to take 20 seconds. I am assuming that this is because of the communication between the PC and the Suns via the NFS mount. Are there any NFS settings I can use to make the data read faster? Is this even the problem? Has anyone faced this problem? Any wisdom on the situation would be helpful. Thanks! Patrick _______________________________________ Patrick O'Reilly Meteorological Decision Support Scientist The STORM Project - University of Northern Iowa patrick.oreilly@xxxxxxx ~ ph: 319-273-3789 http://www.uni.edu/storm "No trees were killed in the making of this e-mail...however, a large number of electrons were horribly inconvenienced."
-- Gerry Creager -- gerry.creager@xxxxxxxx Network Engineering -- AATLT, Texas A&M University Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.847.8578 Page: 979.228.0173 Office: 903A Eller Bldg, TAMU, College Station, TX 77843
ldm-users archives: