On Wed, 5 Dec 2001, Nathan Neulinger wrote: > > 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?
The problem here is that client 2 can't send an update unless its copy of the data is valid. This is required for consistency. It _might_ work; I'd have to read the code, and I don't have time at the moment to reabsorb the cache manager code to the point where I could say for certain. But even if it does work, it will be slow -- if clients 1 and 2 are both using the file, then each time one of them writes, the other will have to refetch the entire file. This is made less of a problem by the normal semantics of not flushing any writes to the fileserver until the file is closed. But that plays havoc with your byte-range locking, since you can't safely release a lock until the relevant data has been written. More precisely, you can't safely release a lock until _all_ the data written to the file while the lock was held has been sent back to the fileserver, even if the data wasn't in the region covered by the lock -- many applications have complex locking models where a lock on one data structure also covers related structures. > Even stage 1 only would be an improvement... Yes, I think it would be an improvement in many cases. It should probably be something that can be turned on and off by an admin. I suggest you submit a patch. -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
