Is there a method to copy LVM and raw devices?

[tommy_28]

There 's a project, we have a AutoRAID SCSI disk subsystem, and we made some PV/VG, lv and raw devices here, and install oracle databases and some applications in these devices.
But after these works we have to shift all contents in AutoRAID to a VA7410. I heard some suggestions to directly copy lvs using dd. I'm not sure it'll work, somebody can give some suggestion?

Thanks.

Tommy

[Jean-Luc Oudart]

Check this thread

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xb4b150dde50cd71190050090279cd0f9,00.html

I suggested HP MirrorUx

Rgds
Jean-Luc

[Stefan Farrelly]

Yes, dd is the best way to copy raw LV's. We use it all the time - never had a problem. Only conditin is the original LV and the new LV must be the same size (in Mb+extents).

Then unmount the filesystems so nobody is using them then dd;

dd if=/dev/vgXX/rlvolYY of=/dev/vgZZ/rlvolVV bs=1024k

Its also the fastest way to copy.

[Leif Halvarsson_2]

Hi,

With Data Protector (and som other backup programs) it is possible to backup/restore raw devices (Disk Images).

[Tim D Fulford]

Hi

As jean Luc has suggested Mirror Disk is a good route, could be done on-line. HOWEVER, not always possible as
o MAY be using kB stripped,
o reached the limit of number of disks per VG
o reached max PEs per PV so that new LUNS on VA will be too small!

I've done the above from FC60 --> VA7400

0 - shutdoen appllications, this must be done OFF LINE (as far as applications accessing the disks are concerned)
1 - Create new VG say vgnew, create ALL the logical volumes (same LV names)
2 - dd if=/dev/vgold/r bs=4096k of=/dev/vgnew/r
3 - Rename vgnew to vgold
# vgexport vgold
# vgexport -m /tmp/vgnew vgnew
# mkdir /dev/vgold
# mknod /dev/vgold/group c 64 0xNN0000
# vgimport -m /tmp/vgnew vgold /dev/dsk/.....

Bingo data back in same format & names as the old VG. BTW take the oppertunity of reviewing the defults of MAX PE/VG, MAX PE/PV, MAX PV/VG etc.

Regards

Tim

[doug mielke]

You might want to take this opportunity to convert away from raw devices. The Oracle 'old school' benefits are all but lost today, and the eva will be much faster than the Autoraids anyway.
and, management on the EVA is a dream.

[Tim D Fulford]

Doug

to raw device or not raw device is a hotly debated issue. Some people swear by raw devices others swear by cooked. They both have advantages & disadvantages.

Tim

[doug mielke]

Tim,
I might be missing some of the advantages to raw devices. I
I have certainly been assuming that touted raw advantages are related to i/o performance, in which case, I know on which side of the fence I sit.

But, Am I missing other advantages to raw not related to i/o speed?

Sign me,
Waiting to be sold,
Doug

[Tim Sanko]

Doug,Tim,Tommy,

We have a EMC Sym 8530 on which we have bechmarked the io difference at < .5 %
raw to cooked using HFS. The difference for vxfs was about .8%. That was with our scenario.

The database is ~= 1.5 T and that was with test benchmarks like the nightly run of daily job. Since we have had such performance from HFS, we have "eschewed" raw file systems. (not a bit sorry about the pun).

Under informix There was be a higher difference
but, we also had an older/slower 3430 symm.


Tim

[Tim D Fulford]

Raw IO Vs Cooked IO

o Resource utilisation, raw uses no HP-UX buffers/memory, cooked uses buffer cache. Effectively your system will hold buffered pages in the database instance & on the OS, you have the same info twice in the same physical memory!!
o raw IO is more efficient, it does not rely on the cooked services to perform IO, cooked IO will need to go to via buffer cache first, then to disk. A well tuned instance will keep its pages in the instance memory.
o Organisation. cooked devices can be "de-fraged" on-line raw will need to be manually manipulated at a database level. After time raw devices performance can suffer from fragmentation (in a bad sense) of data.

It does not surprise me that tests show cooked devices are of similar or better performance than raw or vica versa. BUT as far as system resource usage are concerned they are chalk & cheese. I don't believe there is a right or wrong choice, just that there is a choice, and that it is dependant on your attitude & how big your pocket book is $$$$. If you go for raw, you should be able to save money (probably not much) on memory etc. If you go for cooked, you should be able to keep IO performance levels up over time & not suffer from data fragmentation. The whole area is further complicated by the fact that SANs also have a cacheing area to improve performance.

Regards

Tim

[tommy_28]

Hi,

I have a simular case here, and each VG has more than one PVs.

I plan to mirror all LVs with below steps:

0. Connect both Storage subsystems, define PVs with same size of old PVs.
1. Close all applications use storage subsystem
2. Add new PVs to VG that I would mirror
3. modify VG propertiy, seperate old and new PVs to two PVGs.
4. modify LV mirror policy to use PVG.
5. modify each LV's mirror number to 1
6. split off each LV
7. remove all current LVs
8. mv lv*copy to lv*, and mv rlv*copy to rlv*
9. mount necessary file systems

I've tested above steps in a trial environment, and gonna implement it on customer site.

Is there anything inappropriate?

BTW: I have a basic question, why only 'dd' raw devices, rxxx, after I add a raw disk, there are rxxx and xxx two files in /dev/vgxx.

Thanks&Regards.
Tommy

[Tim D Fulford]

Hi

The question about why there are two LVs a /dev/vgyy/rxxx & /dev/vgyy/xxx.

The rxxx is a character device (as denoted by c at the start of ls -l result) and as such the can be written to/ read from at any block size.

The xxx device is a block device (as denoted by b at the start of ls -l result) and as such can onbly be written / read from at a given block size.

BOTH devices have the same MAJOUR NUMBER (64, lvm kernel device) & MINOR NUMBER 0xNN????. thus they are really the same device (as you already knew)

The reason for dding the raw to raw is that you can pick the block size, I suggest 4096k, but anything greater than 64k is acceptable. If you try & dd the block to block, it may work (I have not tried) but it will be slower than a raw to raw (with a sensible block size, obviously).

Regards

Tim