Excerpts from internet.info-afs: 21-Mar-94 Re: An open letter to
Transarc Pierette_Maniago_Van@tra (3732)
> >* The fs flush/flushv commands do not work reliably. Our cell looks
> > like: (root.afs)(root.cell)(users)(user.username). We recently
> > replicated the volume users and *nothing* short of a reboot got
> > clients to recognize this properly (in some cases, the afs
> > cache had to be "rm -rf"ed too).
> I *believe* the command you wanted was fs checkv. The checkv command
> breaks the psuedo callback on RO volumes (in pre 3.3 releases),
> forcing the cachemanager to refetch RO data from the server. Waiting
> an hour would do the same thing. This may not be the case with a
> newly released volume, but I suspect so. When I did administration, I
> never had to reboot or rm caches to make clients start using RO's.
> (Of course, I did administration a long long time ago).
> Also, I'm not sure of the 3.3 implications given that there are now
> real callbacks on the volume level for ROs.
I have seen this problem many times over the years. It is far less
frequent now than in the past (it happens once a year instead of once a
week). Anyway, there seem to be situations where with readonly volumes
the cache gets corrupt and it is extremely difficult to fix the problem.
There is a better solution than that used by the gentleman from Iowa
State of removing the entire cache and rebooting the machine. If you
modify the corrupt file in the RW, release the volume and fs
checkbackups usually the machine will pick things up. Otherwise, I
think you may have to remove the cache and reboot to fix it.
What I do is move the file to something with a .NEW extension then copy
the file back to its old name. With a corrupt directory I move the
directory, create a new one, then move the contents of the old
directory into the new directory.
I don't know what 3.3 does to all this.
-Wallace
