NFS problems between RHEL4 U3 and RHEL4U6

Chet Nichols III chet.nichols at gmail.com
Tue Jul 22 16:14:43 UTC 2008


for the one where file saving takes minutes, remove the 'sync' option and
replace it with 'async' - see if that fixes the problem
talk to you soon-

chet

On Tue, Jul 22, 2008 at 8:23 AM, <jerry.feldman at algorithmics.com> wrote:

> No. In the case where saving the file takes minutes, there is an fstab
> entry:
> server:/home           /home                   nfs     rw,sync,bg
> In the other one, I have it set up for automounting:
> Auto.master
> /mnts   /etc/auto.mnts          --timeout=60
> Auto.mnts:
> *          -fstype=nfs,rw,nosuid,soft     server:/mnts/&
>
> The fstab and auto.* entries are identical on all of our systems.
>
> The one differences is on the one client system that is running RHEL4U3,
> writing to /home in our test is very fast (about 1 second) where writing
> to /home/<user> on the RHEL4U6 servers takes minutes. But, writing to
> /mnts/buildarea/<user> is also takes about 1 second. On difference is
> the options. I can try a few things.
>
> --
> Jerry Feldman <Jerry.Feldman at algorithmics.com>
> Algorithmics (US), Inc
> Suite 2-400
> 275 Grove St.
> Newton, MA 02466
> 617-663-5220
> 617-663-5391 (fax)
>
>
> > -----Original Message-----
> > From: redhat-list-bounces at redhat.com [mailto:redhat-list-
> > bounces at redhat.com] On Behalf Of Chet Nichols III
> > Sent: Monday, July 21, 2008 5:16 PM
> > To: General Red Hat Linux discussion list
> > Subject: Re: NFS problems between RHEL4 U3 and RHEL4U6
> >
> > are the fstab entries the same on both machines (the working one and
> the
> > not-so-much working one)?
> >
> > talk to you soon-
> >
> > chet
> >
> > On Mon, Jul 21, 2008 at 11:50 AM, <jerry.feldman at algorithmics.com>
> wrote:
> >
> > > I've made a bit of progress on this.
> > > On one o the client machines I am currently not experiencing the
> delay.
> > > But my test on another client I experienced a delay on my home
> directory
> > > but not in another directory (buildarea/foo) both exported by the
> same
> > > NFS server> There is a difference in the export options:
> > > /home                    *(rw,insecure,sync)
> > >
> > > /mnts/buildarea          *(rw,sync)
> > >
> > > Additionally, /home is mounted by fstab on the clients where the
> > > buildarea subdirectories automounted on the clients. I did remove
> the
> > > insecure locking from the /home entry, restarted ns and remounted
> /home
> > > on the clients, but there is no change.
> > >
> > > --
> > > Jerry Feldman <Jerry.Feldman at algorithmics.com>
> > > Algorithmics (US), Inc
> > > Suite 2-400
> > > 275 Grove St.
> > > Newton, MA 02466
> > > 617-663-5220
> > > 617-663-5391 (fax)
> > >
> > >
> > > > -----Original Message-----
> > > > From: redhat-list-bounces at redhat.com [mailto:redhat-list-
> > > > bounces at redhat.com] On Behalf Of jerry.feldman at algorithmics.com
> > > > Sent: Monday, July 14, 2008 9:57 AM
> > > > To: redhat-list at redhat.com
> > > > Subject: NFS problems between RHEL4 U3 and RHEL4U6
> > > >
> > > > My primary NFS server is running RHEL4 Update3 (unpatched). I just
> > > added
> > > > a few servers running U6. (The specific release I run is specified
> by
> > > > our IT department). The problem I am seeing is:
> > > > When I save an 8MB file from our application on a client RHEL4U3
> > > machine
> > > > the save time is about 1 second. When I perform the same test on a
> > > > client running RHEL4U6, the save takes about 2 minutes.
> > > >
> > > > As a test, I exported a directory from one of the RHELU6 systems,
> and
> > > > the save times were good on both an update 3 and update 6 client.
> So,
> > > > one solution is to upgrade U3 to U6. (I would probably do a fresh
> > > > install). But, that requires some downtime, and the server room is
> not
> > > > accessible after hours. (All disks are removable so I probably
> could
> > > > move the volume group to one of the existing servers to minimize
> > > > downtime).
> > > >
> > > > I would like to know if there is some existing NFS issue between
> U3
> > > and
> > > > U6. If I could provide a temporary fix, that would be a better
> interim
> > > > solution until the additional drives I ordered arrive.
> > > >
> > > > --
> > > > Jerry Feldman <Jerry.Feldman at algorithmics.com>
> > > > Algorithmics (US), Inc
> > > > Suite 2-400
> > > > 275 Grove St.
> > > > Newton, MA 02466
> > > > 617-663-5220
> > > > 617-663-5391 (fax)
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> ------------------------------------------------------------------------
> > > --
> > > > This email and any files transmitted with it are confidential and
> > > > proprietary to Algorithmics Incorporated and its affiliates
> > > > ("Algorithmics"). If received in error, use is prohibited. Please
> > > destroy,
> > > > and notify sender. Sender does not waive confidentiality or
> privilege.
> > > > Internet communications cannot be guaranteed to be timely, secure,
> > > error
> > > > or virus-free. Algorithmics does not accept liability for any
> errors
> > > or
> > > > omissions. Any commitment intended to bind Algorithmics must be
> > > reduced to
> > > > writing and signed by an authorized signatory.
> > > >
> > >
> ------------------------------------------------------------------------
> > > --
> > > >
> > > >
> > > > --
> > > > redhat-list mailing list
> > > > unsubscribe
> mailto:redhat-list-request at redhat.com?subject=unsubscribe
> > > > https://www.redhat.com/mailman/listinfo/redhat-list
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > --
> > > This email and any files transmitted with it are confidential and
> > > proprietary to Algorithmics Incorporated and its affiliates
> > > ("Algorithmics"). If received in error, use is prohibited. Please
> > destroy,
> > > and notify sender. Sender does not waive confidentiality or
> privilege.
> > > Internet communications cannot be guaranteed to be timely, secure,
> error
> > or
> > > virus-free. Algorithmics does not accept liability for any errors or
> > > omissions. Any commitment intended to bind Algorithmics must be
> reduced
> > to
> > > writing and signed by an authorized signatory.
> > >
> ------------------------------------------------------------------------
> > --
> > >
> > >
> > > --
> > > redhat-list mailing list
> > > unsubscribe
> mailto:redhat-list-request at redhat.com?subject=unsubscribe
> > > https://www.redhat.com/mailman/listinfo/redhat-list
> > >
> >
> >
> >
> > --
> > ----------------------------------------
> > chet nichols III
> > chet.nichols at gmail.com
> > aim: chet / twitter: chet
> > http://chetnichols.org
> > ----------------------------------------
> > --
> > redhat-list mailing list
> > unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> > https://www.redhat.com/mailman/listinfo/redhat-list
>
>
> --------------------------------------------------------------------------
> This email and any files transmitted with it are confidential and
> proprietary to Algorithmics Incorporated and its affiliates
> ("Algorithmics"). If received in error, use is prohibited. Please destroy,
> and notify sender. Sender does not waive confidentiality or privilege.
> Internet communications cannot be guaranteed to be timely, secure, error or
> virus-free. Algorithmics does not accept liability for any errors or
> omissions. Any commitment intended to bind Algorithmics must be reduced to
> writing and signed by an authorized signatory.
> --------------------------------------------------------------------------
>
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>



-- 
----------------------------------------
chet nichols III
chet.nichols at gmail.com
aim: chet / twitter: chet
http://chetnichols.org
----------------------------------------



More information about the redhat-list mailing list