I use "vxdump 0bfu 63 /dev/rmt/0cbn" to dump vxfs to LTO 2 tape drive.
The dump speed is fast. But when I restore using 
"vxrestore -ivf /dev/rmt/0cbn", it is very slow, like 2G database file
take about 1.5 hours.

The restore speed shouldn't be that slow. Is there any issues about
the restore i am using? Do I need specify block size in the vxrestore
and how?

Thanks a lot for help

Bridge wrote:
> I use "vxdump 0bfu 63 /dev/rmt/0cbn" to dump vxfs to LTO 2 tape drive.
> The dump speed is fast. But when I restore using 
> "vxrestore -ivf /dev/rmt/0cbn", it is very slow, like 2G database file
> take about 1.5 hours.
> 
> The restore speed shouldn't be that slow. Is there any issues about
> the restore i am using? Do I need specify block size in the vxrestore
> and how?
> 
> Thanks a lot for help

i just guess, the verbose flag is the trouble.
when using it on ufsrestore its a pain, might be the same on vx...
/jorgen

Bridge wrote:
> I use "vxdump 0bfu 63 /dev/rmt/0cbn" to dump vxfs to LTO 2 tape drive.
> The dump speed is fast. But when I restore using 
> "vxrestore -ivf /dev/rmt/0cbn", it is very slow, like 2G database file
> take about 1.5 hours.
> 
> The restore speed shouldn't be that slow. Is there any issues about
> the restore i am using? Do I need specify block size in the vxrestore
> and how?
> 
> Thanks a lot for help

Are you using forcedirectio mount option on the filesystem. If so, try 
to disable it during restore.

In article <3e949365.0404231421.3e391a84@posting.google.com>,
Bridge <bridge_xue@yahoo.com> wrote:
>I use "vxdump 0bfu 63 /dev/rmt/0cbn" to dump vxfs to LTO 2 tape drive.
>The dump speed is fast. But when I restore using 
>"vxrestore -ivf /dev/rmt/0cbn", it is very slow, like 2G database file
>take about 1.5 hours.
>
>The restore speed shouldn't be that slow. Is there any issues about
>the restore i am using? Do I need specify block size in the vxrestore
>and how?
>
>Thanks a lot for help

There have been problems with vxrestore doing synchronous I/O and
slowing itself down to a snail's pace as a result. I'll pass this 
on to a colleague who knows about this from bitter experience...

Chris Thompson
Email: cet1 [at] cam.ac.uk

Chris Thompson wrote:
> In article <3e949365.0404231421.3e391a84@posting.google.com>,
> Bridge <bridge_xue@yahoo.com> wrote:
> 
>>I use "vxdump 0bfu 63 /dev/rmt/0cbn" to dump vxfs to LTO 2 tape drive.
>>The dump speed is fast. But when I restore using 
>>"vxrestore -ivf /dev/rmt/0cbn", it is very slow, like 2G database file
>>take about 1.5 hours.
>>
>>The restore speed shouldn't be that slow. Is there any issues about
>>the restore i am using? Do I need specify block size in the vxrestore
>>and how?
>>
>>Thanks a lot for help
> 
> 
> There have been problems with vxrestore doing synchronous I/O and
> slowing itself down to a snail's pace as a result. I'll pass this 
> on to a colleague who knows about this from bitter experience...

I am the said colleague.

If you are using vxfs version 3.4 or later, it might be worth trying
the -c option. The following is from the vsfs 3.5 man page:

     -c   By default, vxrestore writes data directly to disk  and
          does  not  use the system buffer cache to restore data.
          This ensures that the buffer cache does not  change  on
          an  operational system, which generally improves system
          performance.  Writing data synchronously to  disk  may,
          however,  slightly  slow  the  restore process.  If you
          specify the -c option, vxrestore will cache data before
          writing  to  disk.   This  preserves compatibility with
          previous versions of vxrestore.

Veritas made this change in 3.4, but forgot to document it until
3.5. In my environment (vxvm RAID5, average file size large),
the 3.4 vsrestore ran 15 times slower than the 3.2 one, until
I found out about the -c option.

The use of the word 'slightly' in the man page indicates that
no-one at Veritas has tested this version of vxrestore in an
environement like mine.