Re: [OpenAFS] AFS outage, impact of "moving" root.cell.readonly, root.afs.readonly

[Kim Kimball]

Actually, vos remove <server> <partition> <volumename>.readonly  is the easier command vos remsite removes only the RO site info from the VLDB vos zap removes only the RO volume from the server/partition Done one after the other in either order will work fine as you have discovered. vos remove does both -- if I vos zap a volume the VLDB refers to it but it cannot be found where indicated. -- if I vos remsite a volume the VLDB no longer refers to it and it won't be found (after cached volume info is refreshed) -- if I vos remove the VLDB site info is removed and the volume is removed 'vos remove' is the definitive way to remove .readonly volumes.  If removing the clone (RO on same server and partition as RW) be sure to specify .readonly suffix or the RW will be removed without warning. Kim Christopher D. Clausen wrote: Kim Kimball <[EMAIL PROTECTED]> wrote: Sorry for the delay in answering this. Went out of town for a while. Four file servers, all with root.cell.readonly/root.afs.readonly instances. Used "vos remove" to remove one instance of each from one file server. And you did NOT use vos remsite on the replication point first? I suspect that would be a problem. I always vos remsite before vos remove / vos zap the old RO replica. If you don't, I suspect that the vldb might still reference those servers as having RO replicas, even though you removed them with vos remove. Perhaps someone else has the definative guide on removing RO replicas from servers and then removing the .readonly volume. <<CDC _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info