SUMMARY: VRTSvxfs/vxdump problem

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