Summary: Inaccurate copy of filesystem using vdump.

• Previous message: fybar: "Summary: pws 500au intermittent boot problems"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Fri, 19 Mar 2004 12:40:50 -0600
To: "'tru64-unix-managers@ornl.gov'" <tru64-unix-managers@ornl.gov>

This summary is prepared from a query that was original submitted to
tru64-managers back on Feb 24th.

Thanks to those who replied. As usual Dr. Blinn was a great help and
offered some suggestions of things to try.

The systems running 5.1B (which were test not production) were unpatched. I
had reviewed the aggregate patch kit and did not locate any references to a
repair to vdump. However, as part of due diligence I applied the entire
patch kit and the problem went away.

Although not listed as a repair to vdump something in patch kit 3 resolved
the inaccurate vdump/vrestore problem. Dr. Blinn recalled mention of a
vdump problem that was introduced in an earlier patch kit and then repaired
in a later kit. In my case there were no patches installed to begin with.
The system had existed as a full install (all mandatory and all optional
components) from the 5.1B cd.

Additionally, I would like to note that the file command can be used as an
additional check that this problem is being encountered:

> # file /mnt/stage/disk.label {Source file}
> /mnt/stage/disk.label: commands text
> # file /usr6/stage/disk.label {Destination file}
> /usr6/stage/disk.label: data or International Language text

John Farmer

-----Original Message-----
From: Farmer, John
Sent: Tuesday, February 24, 2004 12:23 PM
To: 'tru64-unix-managers@ornl.gov'
Subject: Inaccurate copy of filesystem using vdump.

AlphaServer 4100 running 5.1B (far end of NFS mount) ( mount -t cdfs -o
nodefperm,noversion,rrip /dev/disk/cdrom0c /mnt)

AlphaServer GS60E running 5.1B (near end of nfs mount. i.e. the nfs client)
(mount -t nfs /mnt@ussc38.ussurg.com /mnt2)

I am attempting to copy a remotely mounted cdrom using vdump in the manner
described in the man pages for vdump. I have done this many times before
without incident so I am really unclear regarding what happened this round.
A file named disk.label on the target side of the copy does not accurately
match the file on the source side of the copy. (see below). The copy
contains only nulls.

# mount -t nfs /mnt@ussc38.ussurg.com /mnt2
# vdump -0 -u -f - /mnt2 | (cd /install2 ; vrestore -x -f -)

path : /mnt2
dev/fset : /mnt@ussc38.ussurg.com
type : nfsv3
vdump: Date of last level 0 dump: the start of the epoch
vdump: Dumping directories
vrestore: Date of the vdump save-set: Tue Feb 24 11:32:17 2004
vrestore: Save-set source directory : /mnt2
vrestore: Target directory : /install2
vdump: Dumping 489381888 bytes, 1417 directories, 2414 files
vdump: Dumping regular files
vdump: Status at Tue Feb 24 11:33:00 2004
vdump: Dumped 489918690 of 489381888 bytes; 100.1% completed
vdump: Dumped 1417 of 1417 directories; 100.0% completed
vdump: Dumped 2414 of 2414 files; 100.0% completed
vdump: Dump completed at Tue Feb 24 11:33:00 2004

# cat /mnt2/stage/disk.label

[General]
Label=Tru64 8.1.7
Number=1
Size`0.0
ReservedSize0.0

# cat /install2/stage/disk.label
# exit
Script done, file is /usr/users/JFarmer/mntcopy.log

Any help would be appreciated. I was able to successfully copy the files by
issuing cp -pR but really need to know why the above failed.

John

• Previous message: fybar: "Summary: pws 500au intermittent boot problems"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]