SUMMARY: ADVFS

From: Zbigniew, Ignatowicz <zignatowicz_at_scc.ca>
Date: Fri, 17 Nov 2000 10:33:07 -0500

Hi all,


HI,

I would like to thank all for quick and prompt reply. Most of you mentioned,
that only backup or salvage would help.


First of all, I will summarize what has happened.

I wanted to upgrade to 4.0F to 5.1.
So I started installupdate to 5.0A. I started OK, then it failed. The screen
was frozen. I waited about an hour. There was some messages about
"mntupdata/isl/.. could not find." I read in installation guide, that the
system could not find a cdrom. They said to fix it. But how, if everything
was frozen.

So I decided to reboot and the system bacame not usable at all.

I decided to install clean 5.1. And this went very well. Only I had
root_domain and usr_domain. I though that I can always recover data domains.
I always did that in the past. But I guess I was wrong in version 5.1. I
got the impression from release notes that domains V3 and V4 can co-exist in
5.1.

I ran advscan -g and recreated domains with generic names. Did not compain
about missing volumes. At that point was optimistic, but not for very log.
If tried to mount domain, i got that error.

I managed to salvage one fileset. Others were partially recovered.
Data-wise I was ok, got some backups. Only config files I had to recreate
like APAche, SSL etc....

It was an experience.


Thanks to all again for quick respone.

rbumpu - Robert Bumpus [rbumpu_at_acxiom.com]
Sjolshagen, Thomas [Thomas.Sjolshagen_at_compaq.com]
Robert Mulley [robert_at_gnsconsulting.com.au]
Steven Hancock [shancock_at_zk3.dec.com]
Nikola Milutinovic [Nikola.Milutinovic_at_ev.co.yu]
Johnson, Andrew A. [aajohnson_at_escocorp.com]
Dr. Tom Blinn, 603-884-0646 [tpb_at_doctor.zk3.dec.com]


I am also pasting received responses, because there are some good hints and
might be useful for others.


1.

Check /etc/fdmns/domain_dsk1g and see if there is a link in that directory.
The link should be "diskgroup.volume", which is a link to
/dev/vol/"diskgroup"/"volume". Here's an example: We have the domain
u02_domain, so the directory /etc/fdmns/u02_domain contains a link to an LSM
volume. The link is u02_dg.u02_volume --> /dev/vol/u02_dg/u02_volume. This
may the link that the error mentions. I hope this helps.
 
2.
 
Not sure what you're trying to do here.. What version of Tru64 UNIX are you
using?
 
Remember that AdvFS V3 is Tru64 UNIX V4.0x and AdvFS V4 is Tru64 UNIX V5.x..
 
3.
Somebody must have answered by now but I'll give it a shot. The log
volume is the most important volume in a file domain. File domains can
be multi-volume, ie many disks. Therefore one of the disks is assigned
to deal with the journalling of the advfs file system.

I don't exactly know how you are trying to "recreate a file domain", but
I'm guessing you've moved a disk across. You have to move all disks
associated with the file domain and recreate the links under the
directory: /etc/fdmns/domain_dsk1g
ie if original machine had links such that:
rz8h -> /dev/rz8h
then you need the same thing in your directory on the new system.

Aside from this I don't think you've provided enough info for me to give
a more accurate explanation.

4.

First, I don't think we support multi-volume AdvFS domains
with mixed V3 and V4 on-disk structures. If we allow this
with addvol, it is a bug that needs to be fixed. I don't see
how this could have happend. Can you explain it?

AdvFS is a transaction-based file system, which utilizes a
log to maintain consistent metadata in the event of a
system failure. UFS, on the other hand, is not transaction
based and relies on the fsck tool and proper metadata update
order to correct problems later. The transaction log exists
in any AdvFS domain on a single volume in that domain. Clearly,
the tool (verify in this case) is attempting to activate (mount)
the domain and annot becuse it canot identify the location of
this critical structure.

If the domain will not mount, then salvage may be your only
option. It certainly is worth a try to see if salvage will
get the data for you. Since salvage saves the data to another
location, you can use salvage without disturbing the original
data location. If your backups are good and up-to-date, I
would forgo using salvage and simply remake the domain (in
all the same on-disk structure, v4 preferably) and restore it.

Bottom-line, if the file system is not mountable, you only have
options to either restore or salvage it.

5.
V3 and V4 are incompatible. If you try to mount AdvFS-v3 on DU-v4 you'll
get system_panic.

6.
 
Recreating the link is actually easy as long as you know which device (
/dev/rzb29c for example) is the one with the log on it. How did you lose
the device? I'm thinking you might have added some hardware or did
something which caused the bus numbers to change (that's what's happened on
our system in cases like this). The thing to do is identify the unit number
of the volume, then make sure the devices are made for that unit and then
create the soft link to it in /etc/fdmns/domain_dsk1g.
 
For instance:
 
Say the volume is a raid set called unit D102 on bus 4. The device will be
bus # (4) x 8 + target (1) = 33 and the lun # (2) translates to "c" (a=0,
b=1, c=2, etc.) So the device will be /dev/rzc33. We usually give the
volume the entire disk so it will be partition "c" as well.... /dev/rzc33c.

 
There should already be a link in /etc/fdmns/domain_dsk1g if the domain
already existed. The link shows where AdvFS expects to find the log but
perhaps the device numbers have changed.
 
To find out what your system currently recognizes on the bus, scan and then
show the scu edt.
 
#scu scan edt
 
#scu show edt (This will produce a list of the bus devices the system
"sees") Do the conversion as above to get the device number and make sure
they exist in /dev (for the example above, make sure you see /dev/rzc33c)
If not, create it using /dev/.MAKEDEV rzc33 and then create the link in
/etc/fdmns/domain_dsk1g ( #ln -s /dev/rzc33c rzc33c )
 
I hope this helps. If you need more help, I'll be in the office tomorrow.
Drop me a line and I'll see what I can do, eh?
 

7.

 
When you perform a #showfdmn, on a viable domain, you'll see a log (denoted
with an "L" ) on one of the volumes of the domain. My guess is that it
can't find a log on the volume(s) specified for that domain in /etc/fdmns.
In your example for domain_dks1g, within /etc/fdmns/domain_dsk1g there will
be soft links to devices (volumes) of the domain_dsk1g. Since it can't find
the log file on any volumes listed there, it's probably assuming the links
are not correct and is asking you to recreate the link to the correct volume
that contains the log.
 
8.


The message is telling you that you have a MULTI-VOLUME (more than
one disk) file domain, and that so far you've only provided one of
the volumes (and not the one with the AdvFS log file, which MUST
be present to mount the volume).

You need to go back to the system from which this disk was taken
and figure out the real domain layout.
Received on Fri Nov 17 2000 - 15:34:35 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:41 NZDT