> Unfortunately, you're not only glossing over all the problems with having > the server keep lock state (most of which are not insurmountable); you're > also missing a fundamental problem. If you allow multiple hosts to hold > byte-range locks at the same time, then applications on those hosts will > try to write the file at the same time. The result will be a mess, since > the applications think they have locked the parts of the file they're > updating but the whole-file last-write semantics of AFS mean they really > don't.
So what you're saying is - with the way afs is designed, multiple clients can NEVER safely modify a file simultaneously, even if those clients are accessing completely separate ranges of the file? So even if the one client only sent a single block worth of writes to the file on the server, that cannot be relied upon by other clients? 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. -- Nathan _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
