vxrestore -rf hangs

[Mike Beach]

Hi,

We have several 300GB databases to copy from one filesystem to another. We are getting the best performance with the following command:

vxdump 0f - $SRC|dd bs=8192|(cd $DEST;vxrestore xf - )

However, I don't know how to work around the annoying question:

set owner/mode for '.'? [yn]

I have tried all ways I can think of to pipe the "y" response into the command, but that causes the "y" to be stdin and messes up the pipe.

The easy fix would be to run

vxdump 0f - $SRC|dd bs=8192|(cd $DEST;vxrestore rf - )

However, every time I try this, only 123375 blocks copy and then it just hangs with vxrestore using 97% CPU.

I have tried with and without the dd in the pipe, I even added a dd before the vxrestore as well.

Any ideas on how to make this work unattended?

We are running on HPUX 11.11, VxFS 3.5.

Thanks, Mike

[Peter Godron]

Mike,
can you do anything with the -e ignore option?
Regards

[Geoff Wild]

This is how I did it:

vxdump -0 -f - -s 1000000 -b 16 $SRC | (cd $DEST; vxrestore rf -)

no need to dd

Rgds...Geoff

[Mike Beach]

I didn't think the -e option applied to this situation. I have have added the -e ignore which did not change the result.

vxdump 0f - $SRC|dd bs=8192|(cd $DEST;vxrestore xef ignore - )

vxrestore -rf does not work for the reasons I already gave. Perhaps this is a problem for the response center?

[Geoff Wild]

Try it my way - without the dd - I think the dd is somehow affecting the restore...


Rgds...Geoff

[Mike Beach]

Geoff, thanks for your reply

This command hangs in the exact same block count as before. Here is the cut&paste of the command I ran as you suggested:

vxdump -0 -f - -s 1000000 -b 16 $SRC | (cd $DEST; vxrestore rf -)

For clarification, when I use vxrestore -xf, I do not have this problem.

I have removed the dd for testing, however the copy runs faster with it in the pipe.

[Geoff Wild]

Okay - I get it now..

Here's a dumb question - is there enough space in the $DEST file system?

Also, are they setup the same way? (largefile support, etc, and mounted that way)

fsadm -v $SRC
fsadm -v $DEST


fstyp -v /dev/vgXX/rlvolSRC
fstyp -v /dev/vgXX/rlvolDEST

Rgds...Geoff

[Mike Beach]

The short answer is yes. Keep in mind that I have been running copy tests for a week using vxrestore -xf. The DEST filesystem is absolutely configured to handle it and the restore works correctly, unless I use -rf instead of -xf.

Mike

[Mike Beach]

I have an update. after 1 hour and addition 3G of data was copied using vxrestore -rf.

ordb3te> bdf -l /PCH_DB_NEW
Filesystem kbytes used avail %used Mounted on
/dev/vx/dsk/dbpch/vol01
424225792 123375 397596024 0% /PCH_DB_NEW
ordb3te> bdf -l /PCH_DB_NEW
Filesystem kbytes used avail %used Mounted on
/dev/vx/dsk/dbpch/vol01
424225792 126155 397593415 0% /PCH_DB_NEW
ordb3te>

So, apparently, vxrestore is not completely hung.