On Wednesday 30 March 2005 19:44, ted creedon wrote: > Yes, root.cell.readonly did disappear on both machines. > Looks like it happened when a vos release on doris_disk.vol id 536870944 > was done from hiawatha . Seems to have created bogus.536870944 id > 536870944 on nanook. The byte count on 536870944 was different on both > machines at the time... > > What's the best way to repair? fs mkmounts on both machines? >
bos salvage nanook. Then look at the salvage log. The description of the handling of readonly volumes is described in the following: The bos salvage command salvages (restores internal consistency to) one or more volumes on the file server machine named by the -server argument. When processing one or more partitions, the command restores consistency to corrupted read/write volumes where possible. For read-only or backup volumes, it inspects only the volume header: If the volume header is corrupted, the Salvager removes the volume completely and records the removal in its log file, /usr/afs/logs/SalvageLog. Issue the vos release or vos backup command to create the read-only or backup volume again. If the volume header is intact, the Salvager skips the volume (does not check for corruption in the contents). However, if the File Server notices corruption as it initializes, it sometimes refuses to attach the volume or bring it online. In this case, it is simplest to remove the volume by issuing the vos remove or vos zap command. Then issue the vos release or vos backup command to create it again. Gunther -- ________________________________________________________________ Hans-Gunther Borrmann <[EMAIL PROTECTED]> Rechenzentrum der Universitaet Freiburg Hermann-Herder-Str. 10, D79104 FREIBURG Tel.: +49 761/203-4652 Fax: +49 761/203-4643 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
