On Mon, 14 Apr 2008, Rainer Toebbicke wrote:
We ran into this over a year ago and fixed it, but I must have forgotten to
submit the fix.
It is actually the detection of a "cell" in the mount point string which
triggers the (loosely consistent) fakestat handling - it's treated like a
foreign cell and the mount point is never "completely evaluated", i.e.
logically replaced by the root directory of the volume in question. As a
result, callbacks are ignored, as they go against the directory and not the
mount point.
The attached patch takes care of that.
Thanks a lot for the patch, and to Derrick for pulling it into 1.4.7.
This will allow us to enable fakestat again on certain clients.
- Stephan
(Bcc'ed openafs-bugs)
Stephan Wiesand schrieb:
If a client runs with the -fakestat[-all] option, and has a file cached
that resides in the root directory of a volume affected by fakestat, it
fails to invalidate its cache for this file when it's deleted:
ClientA: touch x
ClientB: ls -l x
... 0 Apr 10 13:10 x
ClientA: echo a >> x
ClientB: ls -l x; cat x
... 2 Apr 10 13:11 x
a
ClientA: rm x
ClientB: ls -l x; cat x
... 2 Apr 10 13:11 x (!)
a (!)
ClientA: echo b > x
ClientB: ls -l x; cat x
... 2 Apr 10 13:11 x (!)
a (!)
ClientB: fs flushv; ls -l x; cat x
... 2 Apr 10 13:12 x
b
I guess it's the same issue reported by Jack Neely on March 17th. We're not
running with -fakestat-all, just -fakestat. The problem struck when mount
points for local volumes were accidentally created with the -cell option.
We can reproduce the problem with local and foreign volumes. Turning off
fakestat eliminates it reliably.
We observe this with various Linux clients. OpenAFS 1.4.6 or 1.4.7pre3,
SL3/4/5, 32/64-bit.
An SL3 client still running 1.2.13 does not exhibit this problem.
Bcc to openafs-bugs.
--
Stephan Wiesand
DESY - DV -
Platanenallee 6
15738 Zeuthen, Germany
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
