Fellow Digital Unix Managers,
I posted a question a month ago about AdvFS inconsistency. I got some
answers. I have not test for any solution yet. I have reformatted the disk and
have restored the data from backup tape. Thanks to the following people for
answering.
ron_barrett_at_corp.Cubic.COM
<jim_at_orac.ecc.tased.edu.au>
alan_at_nabeth.cxo.dec.com
<Ray.Bellis_at_psy.ox.ac.uk>
<Knut.Hellebo_at_nho.hydro.com>
khan_at_fbi003.informatik.fh-hamburg.de
<mwragovt_at_star.net>
These are the summaries.
Suggestions to use the tools in /usr/field.
I have used those but since the domain cannot be mounted. They could
not work on it.
Make sure that no partitions are overlapping rz0f.
I have checked for overlapping partitions and there were none.
I/O error in the log or other part of file system metadata. No offline repair
tool. Restore from backup.
This is exactly what I have done. But this is not acceptable for a
production file system to behave this way.
Only some DEC drives are supported for AdvFS.
Although this is the official line, I don't see the reason behind it.
Being supported only means Digital has tested it against their software.
Finally, last week, there is a message on the list about fixing AdvFS
inconsistencies. I have not tested the solution. If someone has the same
problem, they may be able to use this.
From matt_at_perutz.salk.edu,
I ran into some AdvFS inconsistencies that prevented a filesystem from being
mounted. I had no luck with the programs in /usr/field. Here's what did work:
# dbx -k /vmunix
(dbx) patch AdvfsFixUpSBM = 1
<dbx returns "1">
(dbx) quit
# reboot
Evidentally this signals the kernal to fix Advfs inconsistencies at the next
boot. I hear that you may have to do this more than once to fix things up.
It worked for me on the first try. Use at your own risk!
Hope the last solution would work for you too.
-lee
Received on Fri Jan 12 1996 - 19:41:21 NZDT