Mailing List Archive

>
> I've noticed that when I make a change on an nfs mounted file system on my
> Netapp from one machine, it sometimes takes anywhere from a few seconds to
> a minute for other machines that access the same nfs mounted file system to
> see the change I made from the first machine. The clients are unix and
> linux machines.
>
> Example: On my admin host (unix machine), I change permissions on an
> exported directory. A unix client that automounts this directory takes 20
> to 30 seconds before I see the directory permissions change.
>
> Anyone else experience something like this? What sort of things should I be
> checking to reduce or eliminate this delay?

Try checking the date/time on the filer and the NFS clients. I think
you can run into these sort of problems if there are discrepancies.

Steve Losen scl@virginia.edu phone: 434-924-0640

University of Virginia ITC Unix Support

On Mon, Aug 12, 2002 at 11:51:37AM -0400, Steve Losen wrote:
>
> >
> > I've noticed that when I make a change on an nfs mounted file system on my
> > Netapp from one machine, it sometimes takes anywhere from a few seconds to
> > a minute for other machines that access the same nfs mounted file system to
> > see the change I made from the first machine. The clients are unix and
> > linux machines.
> >
> > Example: On my admin host (unix machine), I change permissions on an
> > exported directory. A unix client that automounts this directory takes 20
> > to 30 seconds before I see the directory permissions change.
> >
> > Anyone else experience something like this? What sort of things should I be
> > checking to reduce or eliminate this delay?
>
> Try checking the date/time on the filer and the NFS clients. I think
> you can run into these sort of problems if there are discrepancies.

I've seen the same thing, and I have ntp everywhere. Do you use
(t)csh? rehash might help.

Igor

Directory attributes are cached on the client-side (timeout is usually in the
30 sec range). If you list out a dir and then change perms from a different
client, the original client won't see the updated perms until it's attr cache
timeout is exceeded. Client-side attr cache timeouts are adjustable with mount
options ... look at your client's version of 'man mount_nfs' for details.

*********** REPLY SEPARATOR ***********

On 8/12/02 at 1:17 PM Igor Schein wrote:

>On Mon, Aug 12, 2002 at 11:51:37AM -0400, Steve Losen wrote:
>>
>> >
>> > I've noticed that when I make a change on an nfs mounted file system on my
>> > Netapp from one machine, it sometimes takes anywhere from a few seconds
to
>> > a minute for other machines that access the same nfs mounted file system
to
>> > see the change I made from the first machine. The clients are unix and
>> > linux machines.
>> >
>> > Example: On my admin host (unix machine), I change permissions on an
>> > exported directory. A unix client that automounts this directory takes 20
>> > to 30 seconds before I see the directory permissions change.
>> >
>> > Anyone else experience something like this? What sort of things should I
be
>> > checking to reduce or eliminate this delay?
>>
>> Try checking the date/time on the filer and the NFS clients. I think
>> you can run into these sort of problems if there are discrepancies.
>
>I've seen the same thing, and I have ntp everywhere. Do you use
>(t)csh? rehash might help.
>
>Igor


Marty Johnson

tlongo@avaya.com (Tim Longo) writes:
>
> I've noticed that when I make a change on an nfs mounted file system on my
> Netapp from one machine, it sometimes takes anywhere from a few seconds to
> a minute for other machines that access the same nfs mounted file system to
> see the change I made from the first machine. The clients are unix and
> linux machines.
>
> Example: On my admin host (unix machine), I change permissions on an
> exported directory. A unix client that automounts this directory takes 20
> to 30 seconds before I see the directory permissions change.

This is the "attribute cache" on the client system. Doing a stat(2) on a
file or directory will use a cached value if it's not too old, rather than
doing an RPC to the server on every occasion.

> Anyone else experience something like this? What sort of things should I be
> checking to reduce or eliminate this delay?

There are usually mount options to control the operation of the cache,
which should be described in the man page, and the defaults will probably
be described there as well. For Solaris (Your Unix May Vary!) you can set
"acregmin", "acregmax", "acdirmin", "acdirmax" to control minimum/maximum
times in the cache. Or you can set "noac" to turn off attribute caching
altogether, but note that that will increase NFS network traffic, often
substantially.

Actually reading or writing the file should bring the attributes up to
date on the client (at least with nfs v3, as they are returned for free
by the server).

Chris Thompson
Email: cet1@cam.ac.uk