If the CM omits to flush in this case, that's a plausible result. Viced will BCB when the lock is released, but if the changed data hasn't been written back, the cooperating clients lose.
Matt ----- "Simon Wilkinson" <[email protected]> wrote: > > I strongly suspect that the copy on the client is up to date, at least > > according to the server. However, it may well be out of data according > > to the machine which made the modification. That machine only writes > > its changes back to the server on receipt of a fflush or close (or > when it's cache fills, and it needs to shed some dirty chunks). > > So, if there is a problem here, it's going to be related to the fact > > that we aren't flushing when a lock is released, rather than our > behaviour on obtaining a lock. Perhaps you could verify that case? > > Cheers, > > Simon. > > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info -- 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 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
