On Fri, 2 Sep 2011 17:04:10 -0400 (EDT) Richard Brittain <[email protected]> wrote:
> As expected, most clients get an error if the vos rename has happened, > but not the rmmount/mkmount/release (since the mount points are > replicated). However, a client with an open file on the volume seemed > to be fine and continued to work after rename, and even reported the > correct voluume name to 'fs lq'. Clients cache vldb information (which includes name <-> id mappings, as well as location information) for 2 hours. So if you're reading or writing to a volume when you do the rename, the client will not notice, since it knows it is writing to volid 1234, and doesn't care what the name is. If you have not accessed the volume recently (or you've issued 'fs checkv', or some error causes a re-lookup), it'll try to look up the old name and fail. Userspace tools look up volume names / ids / etc every time they are run, though, so 'fs lq' will interpret the volume id according to the most recent information. So it's not really "safe" since a client's cache could become stale without you knowing, and it would cause accesses to that volume to suddenly fail. That failure is a bit unlikely if you do the switch relatively quickly, but it is certainly possible. A more safe way to do this would be to allow you to add a volume name alias in the vldb or something, so you could add the new name, update mountpoints, and remove the old name. We don't provide a way to do that. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
