[AFS3-std] File Server/Cache Manager Extended Status Information

[Matt Benjamin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jeffrey Hutzelman wrote:
| --On Monday, April 07, 2008 12:30:06 PM -0400 Matt Benjamin
|
| You'd think that, but the problem is that you generally can't.  Cache
| consistency demands that when a file's contents are changed, you break
| callbacks to any online clients before the RPC that made the change
| returns.  That means you can't queue them up to combine later.
|

That avoids saying what the cache consistency guarantee in AFS is,
though it's not in doubt--even if I do misunderstand some aspect of it,
or the whole thing. :)

In AFS today, if clients A and B have made changes in a file, and have
not stored, there is a race to store.  I do not think the race is
eliminated by the fact that the call back break from the
first-client-to-store (say, A) is executed before the clients store
completes.  This cannot undo the changes made on B before it received
the call back break (that B must store or discard).  (I assume we don't
send a call back break to A in that case, but I haven't looked.)

In the case of lock-coordinated access to regions of a file, we expect
that B's client's cannot write to a range R(A), until A's lock is
released.  So there is no race to store.  If we were queuing changes to
combine later, seems like it would suffice that queued changes to R(A),
if any), be flushed when A's lock is released.  Before that, it seems
they could be best-effort--and are anyway.

Matt

- --

Matt Benjamin

The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH+mPjJiSUUSaRdSURCGNnAJ97QYzkEcloBAR8Z+086N+ZeKYUgACfUhKi
IBp/gPhYozCnNI6QpMl7R7E=
=e8TT
-----END PGP SIGNATURE-----