Well, due to the holiday weekend, there was not much response, but time
allowed me to figure things anyway! Thanks to Alan Rollow
(alan_at_nabeth.cxo.dec.com) who told me how to get started analysing the
problem (ie, check the error logs to see if it was a real i/o error).
First, I believe the original fault was caused by a SCSI termination
problem - advfs didn't just trash the disk as a random occurrence.
Possibly something to do with having an external (narrow scsi) tape
drive on the wide scsi bus of the Alphastation. The error log contained
only corrupt entries from this boot (so I guess that in some ways we
were lucky the UFS filesystems of the system disk didn't suffer damage
from the fault).
What was odd was that even after correcting termination, none of the
advfs utilities, including "salvage" would do anything with the trashed
drive. However, when the drive was moved to a completely different
system, "salvage", using with the -S option to perform a block-by-block
search of the partition, started working and recovered all files from
the filesystem. The only remaining gripe is that salvage would segfault
whenever I tried to specify a date, so I could select only files changed
since the last backup date. But I shouldn't really call this a gripe, as
I am grateful for salvage being supplied; it did its job.
Graham
------
Original question:
> After rebooting one of our systems, an Alphastation 500 running DU40.d
> with patch kit 1, the filesystems on an advfs domain failed to mount.
>
> Booting single-user, and running /sbin/bcheckrc, I get (for all the advfs
> filesets on that, the only, domain):
>
> domain#fileset on /mount-point: I/O error.
>
> Running /sbin/advfs/verify domain gives:
>
> verify: can't get set info for domain 'domain'
> verify: error = ENO_XTNTS (-1036)
> +++ Domain verification +++
> main: unable to get info for domain 'domain'
> error: -1036, ENO_XTNTS (-1036)
>
> Which doesn't look good. Is there any hope of recovering this (most
> filesets are backed up, but not all, so a recovery would be nice). The
> domain is contained within a single disk partition, so it is at least
> not too complicated.
--
Received on Tue May 26 1998 - 16:12:08 NZST