Gerrit 8197 makes the unix client effectively ignore advisory lock requests for files in RO volumes. I'm pretty sure this is okay, but I just wanted to raise it here to give people more of a chance if there's any possible issues with that.
This should be okay, since for an RO vol, there's no writes that we can conflict with from another process. There should be no write locks we can conflict with, since a process cannot issue a write lock for a file opened read-only, and you can only open files read-only in an RO vol. And the fileserver already does not track locks for RO vols, which makes me think I'm not missing anything. At some point I thought maybe it would be possible for processes to misuse locks as some kind of general IPC mech or something, which ignoring them would disrupt (whereas right now they are tracked in-kernel even if not on the fileserver), but... I'm not even sure that's detectable by an application. Since, afaik you can only ask if there is a conflicting lock held, not just "are there read locks" or something. -- Andrew Deason adea...@sinenomine.net _______________________________________________ OpenAFS-devel mailing list OpenAFS-devel@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-devel
