It's always a good idea to routinely collect volume usage information, that way you know for sure how busy a volume is and has been in the past. I do a "vos listvol -extended" call on all my file servers hourly. In one instance that I can remember it actually did provide a precursor that an hardware failure was starting to happen as it impacted this hourly query when the results from the failing AFS partition were being returned very slowly (SCSI transport error)
On Sun, Mar 5, 2017 at 10:22 PM, Benjamin Kaduk <[email protected]> wrote: > On Sun, Mar 05, 2017 at 08:48:20PM -0500, Garance A Drosehn wrote: > > On 20 Feb 2017, at 16:07, Garance A Drosehn wrote: > > > > While 'listvol' of the broken file server shows those volumes, > > if I do a 'vos examine' for each volume then the VLDB shows > > the volumes exist on other file servers. This makes sense, > > since the vos-moves had failed before they finished. > > > > I'm pretty confident that all I need to do now is enter the > > commands so the file server is completely removed from our > > cell. Then I'll destroy these virtual disks, create some new > > virtual disks and use those to build a new file server, from > > scratch. > > That does seem to follow from the previous paragraph. > > Glad you've got things settled without too much excitement. > > -Ben > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info > -- | | Terry McCoy email: [email protected] | Sr Systems Engineer phone: (574) 631-4274 | | Office of Information Technologies | B014 Information Technology Center | University of Notre Dame | Notre Dame, Indiana 46556
