SUMMARY: VRTSvxfs/vxdump problem

From: Martin.Carmichael@dial.pipex.com
Date: Thu Jan 09 2003 - 08:09:43 EST


Hi,
   On further testing, I believe the problem is that the filesystem had not
been flushed from memory to disk. Since vxdump (and ufsdump) backs up the rdsk
device, therefore all of the filesystem was not being backed up. My solution is
to perform a "sync" before performing the backup.

  I know that it is advised not use vxdump/ufsdump on a mounted filesystem,
probably because of the above. But there are cases where it is not possible to
unmount a filesystem (or not enough disk space for a snapshot). We normally do
backups at night on "quiet" filesystems. Have not had any probelms restoring,
but maybe we have been lucky. I will be changing our scripts to perform
a "sync" before each backup to be on the safe side.

Regards
Martin

Original message:

> Hi,
>
> This is not a Solaris problem (?) but I am posting to see if anyone has
> experienced this strange problem. We have posted to Veritas forum and
> logged
> call with SUN, but, as yet, have not received solution, etc. Problem is
> with
> VRTSvxfs vxdump command.
>
>
> It appears that when a vxfs filesystem is created and data loaded into
> it, vxdump does not save the filesystem completely. If the filesystem is
> umounted and remounted then everything is ok (???). I am also sure that
> a
> format/analyze/read of the disk instead of a filesystem remount appears
> to also
> solve the problem.
>
> The following is a note of the versions we are running
> OS: Solaris 2.6 (kernel patch 105181-33)
> vxfs: VRTSvxfs 3.4,REV=GA03
> vxfs patch: 110433-07 (latest patch)
>
> I have trolled through mailing lists, SUNSolve, etc but cannot find this
> problem. I did find references to a vxdump problem which was
> re-introduced
> into vxfs 3.4 but I believe it was fixed in patch 110433-02.
>
>
> The following is an example of the problem:
>
> # mkfs -F vxfs /dev/rdsk/c2t4d0s0 1229832
> version 4 layout
> 1229832 sectors, 614916 blocks of size 1024, log size 1024 blocks
> unlimited inodes, largefiles not supported
> 614916 data blocks, 613676 free data blocks
> 19 allocation units of 32768 blocks, 32768 data blocks
> last allocation unit has 25092 data blocks
> #
> #
> #
> # mount -F vxfs /dev/dsk/c2t4d0s0 /martinc
> #
> #
> # cd /var
> # find . -print | cpio -pmd /martinc
> 538299 blocks
> #
> #
> # df -k /martinc
> Filesystem kbytes used avail capacity Mounted on
> /dev/dsk/c2t4d0s0 614916 271678 321824 46% /martinc
> #
> #
> # vxdump 0f /export/home/martinc.vx /martinc
> vxfs vxdump: Date of this level 0 dump: Tue Jan 7 14:10:32 2003
> vxfs vxdump: Date of last level 0 dump: the epoch
> vxfs vxdump: Dumping /dev/rdsk/c2t4d0s0 to /export/home/martinc.vx
> vxfs vxdump: mapping (Pass I) [regular files]
> vxfs vxdump: mapping (Pass II) [directories]
> vxfs vxdump: estimated 356598 blocks (174.12MB).
> vxfs vxdump: dumping (Pass III) [directories]
> vxfs vxdump: dumping (Pass IV) [regular files]
> vxfs vxdump: vxdump: 178581 tape blocks on 1 volumes(s)
> vxfs vxdump: Closing /export/home/martinc.vx
> vxfs vxdump: vxdump is done
> #
> #
> # vxrestore ivf /export/home/martinc.vx
> Verify tape and initialize maps
> Tape block size is 63
> Dump date: Tue Jan 7 14:10:32 2003
> Dumped from: the epoch
> vxfs vxrestore: cannot preserve extent attributes
> level 0 dump of on /dev/rdsk/c2t4d0s0
> Extract directories from tape
> Initialize symbol table.
> vxrestore > ls
> .:
> 3 lost+found/ 4 sadm/
>
> vxrestore > q
> #
> #
> # ls /martinc
> adm dmi lp ntp saf tmp
> audit dt mail opt snmp uucp
> crash log news preserve spool vxvm
> cron lost+found nis sadm statmon yp
> #
> #
> #
> #
> #
> #
> # umount /martinc
> # mount -F vxfs /dev/dsk/c2t4d0s0 /martinc
> #
> #
> #
> # vxdump 0f /export/home/martinc.vx /martinc
> vxfs vxdump: Date of this level 0 dump: Tue Jan 7 14:11:38 2003
> vxfs vxdump: Date of last level 0 dump: the epoch
> vxfs vxdump: Dumping /dev/rdsk/c2t4d0s0 to /export/home/martinc.vx
> vxfs vxdump: mapping (Pass I) [regular files]
> vxfs vxdump: mapping (Pass II) [directories]
> vxfs vxdump: estimated 545270 blocks (266.25MB).
> vxfs vxdump: dumping (Pass III) [directories]
> vxfs vxdump: dumping (Pass IV) [regular files]
> vxfs vxdump: vxdump: 273093 tape blocks on 1 volumes(s)
> vxfs vxdump: Closing /export/home/martinc.vx
> vxfs vxdump: vxdump is done
> #
> #
> # vxrestore ivf /export/home/martinc.vx
> Verify tape and initialize maps
> Tape block size is 63
> Dump date: Tue Jan 7 14:11:38 2003
> Dumped from: the epoch
> vxfs vxrestore: cannot preserve extent attributes
> level 0 dump of on /dev/rdsk/c2t4d0s0
> Extract directories from tape
> Initialize symbol table.
> vxrestore > ls
> .:
> 2790 adm/ 2819 log/ 2913 ntp/ 2843 spool/
> 2815 audit/ 3 lost+found/ 2831 opt/ 2934 statmon/
> 2948 crash/ 2915 lp/ 2838 preserve/ 2888 tmp/
> 2816 cron/ 2827 mail/ 4 sadm/ 2895 uucp/
> 2920 dmi/ 2830 news/ 2839 saf/ 2945 vxvm/
> 2938 dt/ 2906 nis/ 2928 snmp/ 2907 yp/
>
> vxrestore > q
>
>
>
> Regards
> Martin
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers



This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:25:33 EDT