> Not with the current protocol. That sort of capability would require > block-level callbacks and data version tracking, which could quickly get > messy. I'm not saying its impossible, but it would require considerable > additional work, and might turn out to impact performance too much.
I guess the thing I don't understand is - why does it matter what the cache says? i.e. client 1 and 2 open file, client 1 sends changes to server and closes. At this point, the cache is invalid on client 2, but the application on client 2 then sends a block of changes to the server. Is the result not predictable at that point? I don't see why it wouldn't be. Why does client 2 care what's in the cache if it's just sending a write? Now I can see how a read on client2 might not get the data it had just written if the file hadn't been closed. I suppose that's probably the problem you're meaning. Perhaps write through would be a requirement if multiple hosts have locks on the same file? > > I guess what that implies is that the stage 1 (client side only > > upgradable locks) are the best that we can do without completely > > changing the way afs works. That would be an improvement - at least apps > > on the same box can have fully functional locking support. > > Without a significant protocol change, yes, stage 1 is the best we can do. Even stage 1 only would be an improvement... _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
