Discussion:
How to flush cache
(too old to reply)
Scott
2012-04-25 02:49:10 UTC
Permalink
I have two Solaris 10 hosts and a NetApp.

host1# cd /net/filer1/vol
host1# ls -l
vol2_sata ....
(On filer1, rename volume from vol2_sata to flight_data)
host1# ls -l
vol2_sata ... (still shows vol2_sata name)
How can I invalidate Solaris's view of filer1 so I can see the renamed
volume?

Meanwhile, on host2, where I did not cd /net/filer1/vol before I
renamed the volume:
host2# cd /net/filer1/vol
host2# ls -l
flight_data .... (sees new flight_data name)

I seem to remember having this problem a year or two ago, opened a
trouble ticket on it, and I thought I was told an ls -l would cause
Solaris to reread attributes from the server, refreshing its cache.
As I can see, ls -l isn't doing this for me today.
I've tried restarting nfs/client, nscd -i, and restarting autofs.

Regards, Scott
Casper H.S. Dik
2012-04-25 07:47:41 UTC
Permalink
Post by Scott
I seem to remember having this problem a year or two ago, opened a
trouble ticket on it, and I thought I was told an ls -l would cause
Solaris to reread attributes from the server, refreshing its cache.
As I can see, ls -l isn't doing this for me today.
I've tried restarting nfs/client, nscd -i, and restarting autofs.
NFS doesn't uses names, it uses file handles; even if a file is renamed,
the file keeps the file handle and refreshing its attributes will
still work. The directory containing the file should have changed
so I would think it should be able to find the new file.

Casper
Scott
2012-04-25 16:29:49 UTC
Permalink
Post by Casper H.S. Dik
Post by Scott
I seem to remember having this problem a year or two ago, opened a
trouble ticket on it, and I thought I was told an ls -l would cause
Solaris to reread attributes from the server, refreshing its cache.
As I can see, ls -l isn't doing this for me today.
I've tried restarting nfs/client, nscd -i, and restarting autofs.
NFS doesn't uses names, it uses file handles; even if a file is renamed,
the file keeps the file handle and refreshing its attributes will
still work.  The directory containing the file should have changed
so I would think it should be able to find the new file.
Casper
I found some information on it - the problem is related to the
automounter maintaining the /net directory.

Symptoms
If the automounter on an NFS client has already mounted a -hosts map
(e.g. /net) for an NFS server it will not show file systems later
exported on that server. The automounter only looks at the list of
exported filesystems from a particular host via the -hosts map at
the time it is mounted and does not refresh the list.

Resolution
There are at least three different ways to resolve this:

1. Wait for the /net mount to time-out and be unmounted.

2. Use a different but equivalent name for the host:

/net/foo
/net/foo.uk
/net/FoO.uK
/net/foo.uk.sun.com
/net/129.1.2.3

Each one will be a new 'view' on the exported directories.

3. Reboot

#1, above, really doesn't work.
What I've found is if I wait overnight the problem still will not
clear itself.
That means even though the /net/filer1/vol/vol2_sata is not mounted
nor does
it even exist, it also doesn't clear itself up.
However, if I svcadm disable autofs, then:
# sleep 600; svcadm enable autofs
I get a new shot at browsing/retrieving the exports of /net/filer1/
vol.

So far, that's the quickest way to resolve the issue.

Regards, Scott

Loading...