John,
I admit that like someone else's post - I usually use cpio - because, I admit - I like the output on the screen better :-) . But, I think that cp is going to provide good throughput.
Alas, I'm not familiar with vxdump, and haven't given it much thought - however with Geoff's mention that he's done a number of SAN migrations with it - I'll definitely be looking it over and evaluating it for my next SAN migration. So, my answer is - it's easy enough to test these tools, and get some rough numbers - so I think you should give vxdump a try. My earlier recommendation was based on the fact that it sounded like you're a bit new to this, and it would be the easiest in concept to use and gauge how you're doing during the process.
Best is to do some sample tests, and measure your throuput - you can do this even on "open" or hot database file. Of course, the resultant files won't be any good - it's a throwaway, but you should be able to go into a subdir and get some time estimates which will tell you which way is faster.
That being said - there's a lot consider when you created your new volume on your Hitachi SAN. Did you expose all of your LUNS to your HP box as one big LUSE ? I find that the Hitachi techies really like this method - but fail to consider that HPUX is going to give you much better throughput to multiple LUNS interleaved via distributed stripes (to the PE size) to your SAN device. I find that Hitachi's implementation method may vary from what HP might do implementing an Hitachi rebranded device (XP1024, XP512). I generally use OPEN-9 or OPEN-E and combine at most two together in a LUSE configuration for high I/O database areas. Your access to lot's of devs and interleaving them is going to provide you a fair amount of I/O bandwidth to your storage frame, but could be a limitation without. Hopefully you installed a healthy amount of I/O cards to make it happen.
Anyways... cpio would be...
cd /source_mnt_point
find . | cpio -pdmvu /targe_mnt_point
another interesting that may work well (you'll need to time it) that I use most often between servers (not on the same server - which is what you're doing) is tar. For you, it would look like...
cd /source_mnt_point
tar cvf - . | (cd /target_mnt_point ; tar xvf - )
to get timings - use the "time" command in front of any command you want to run.
Just be careful during your tests not to trash your production databases - right?
Since you know you're kind of new at this, go and find an old test box to play with. I've kept old boxes just for this very purpose for our newest sys admins and they admit that without them they would have never learned nearly as much. You need a place to be able to make mistakes and fix them without breaking production.
Lastly, keep in mind that if you've got one of the Hitachi systems, they can easily handle a great deal of concurrency. This means that you can copy with many jobs at once. I'd probably restrict this to one job per file system - because you don't want to get your database files all fragmented up ( I do realize you're doing just one filesystem ). But, just a general question - is the best solution just one file system? Is this just an app - or an app with databases or binary files in it that are database-like?
We are the people our parents warned us about --Jimmy Buffett
