At work we have a couple of occasions where we want to make access to a volume be read-only. For example, when we do a restore for a user we don't want the user to be able to write stuff there. Or it might be useful when we get a request from the User Advocate or ITSS (IT Security Services) office to freeze an account to freeze the afs volume associated with the account.
Right now, when we do a restore, we run the restore with the -readonly flag, which marks the volume as a RO volume. This, of course isn't really a read-only volume, rather, in classic afs sense, this is a read-only version of a replicated volume. While it works in a pragmatic sense, there's no corresponding read-write volume, which really confuses vos (and me, when I try examining the volume and have to remind myself why I'm seeing weird output). Plus, this doesn't handle the "we need to lock this volume now" instance. Sure, we could change the volume's top-level ACL to do this, but again this is doing some other operation to fake what we really want to do.
Now, there is a -readonly flag to the fileserver, which basically makes all write operations to any volume on that fileserver fail with VREADONLY. And, this actually does exactly what we want, but it means you have to maintain at least one fileserver that is specifically a read-only server, and move/restore any volume you want to be read-only there.
What I really want, however, is a vos command that simply locks a volume. Since the term "read-only" is used otherwise in afs, I think I'd like it to be something like vos writelock -lock and vos writelock -unlock.
After staring at code, I think it would be fairly simple to do. In vol/volume.h take the first of the reserved2 array to be a flag for this, add a macro to see if that field is set, where all the other (vp)->header->diskstuff macros are set. Then in viced/afsfileprocs.c everwhere that you see if (readonlyServer) return (VREADONLY); add another check to see if the flag above is set and, if it is, also return VREADONLY. This would be fairly trivial.
The other side of this would be adding even more stuff to volser/vos.c, adding support for the writelock command, and also support to have vos examine return info about if the volume is writelocked. This is a little more complicated, because this involves adding another RPC and changing what UV_ListOneVolume returns. I may also want to overload the offline message in the volume header and allow writelock to set some small string in there.
I started looking at the 1.4.8 code, but with the previous paragraph, I should probably look at whatever the latest 1.5 series is, and put it in there, since this is likely enough of a change to not go into the maintenance release.