TABLE OF CONTENTS In this section, we discuss basic AdvFS troubleshooting techniques. We begin with recovery from domain panics, then move on to AdvFS I/O errors that you may sometimes see in the syslog files, cover some methods for dealing with corruption in an AdvFS domain, and finally finish up with discussions of the verify(8) and salvage(8) tools.
In some instances, usually in the case of log or metadata write failure, the system takes a nonroot domain offline rather than panic. A domain panic prevents further access to the domain but allows filesets in the domain to be unmounted. Typically, an AdvFS domain panic signals a hardware problem; however, it may also indicate a software failure, particularly in a domain that contains critical system files, such as the root file system. AdvFS also periodically examines metadata, particularly after reading it from disk, and forces a domain panic if it detects corruption.
The benefit of an AdvFS domain panic is that it prevents further access by users to a single AdvFS file domain and allows the filesets in that domain to be unmounted and examined. In addition, all other AdvFS domains remain on line and in normal operation, unaffected by the domain panic. A domain panic message is logged with the following format:
AdvFS Domain Panic; Domain <i class="emphasis">name</i> Id <i class="emphasis">domain_id</i>
Normally, these domain panic messages are logged into the /var/adm/ messages file. Beginning in 4.0D, they are also logged into the /var/adm/...
