dd between lvols of different size

[Ricardo Rocha]

Hi

I intend to migrate data from 2 different storages on hpux. The idea is to create similar LVM structure and to copy the data using dd's between lvol's.

Unfortunately, due to disks size, I can't use the same PE size that was used before (4MB). Probably I will use 8MB or even more.

This causes to the original lvol to be a little bit smaller than the new one (4MB smaller).

Will the dd work? Will I be able to fsck and mount the new lvol?

Thanks in advice,

RR

PS- Points will be given!!!

[A. Clay Stephenson · Accepted solution]

As long as the destination LVOL is at least as big as the source LVOL, all will be well. The PE size is completely invisible to dd (or any other i/o operation) and will not be a problem. Make sure that you specify a bs=1024k (or so) blocksize; otherwise, the default 512-byte block will be very slow. You should also specify ONLY bs=xxx rather than ibs=xxx obs=yyy to avoid an input to output buffer copy inside dd.

[Bill Hassell]

Actually, you can skip the fsck step -- just unmount the source volume and use the raw device files for both source and destination. Once complete, you can immediately mount the destination lvol. I would not recommend copying an active lvol -- the result will contain data problems that fsck cannot fix (fsck only fixes directory problems)

If the destination is larger than the source, the filesystem won't know this and will function as if the lvol did not change size. To get the filesystem to use the additional space, run extendfs on the raw devicefile for the destination. Then you can mount the lvol.

[Ricardo Rocha]

Thanks,

All original lvols won't be mounted, as they will probably belong to XP Business Copy luns.
I intend to import the vg and then dd the data into the new structure.
Of course, we will stop all aplications just before we split the BC.
This way I could the easily use dd of rlvols, right?

Thanks,

Ricardo

[Bill Hassell]

Correct. dd is most effective (highest performance) when using raw volumes because the driver bypasses the buffer cache in RAM. Note the importance of bs=1024k as mentioned. As with all disk performance techniques, reducing the number of individual I/O's is very important since the overhead to get the I/O started and finished is very significant. For the default bs=512 this overhead can be more than 50% of the total time while for bs=1024k, it is less than 1-2% depending on the interface and disk density and rotation speed. Buffering in the disk and/or controller only affect short tasks--a large dd will exhaust all the hardware buffering after a short time and the real disk speed becomes the limiting factor.

[Ricardo Rocha]

Thank you all.