bdf not correct after copy using dd

[Ganesan R]

Hi,

I used dd to copy 16GB data from one LV to another LV.
#dd if=/dev/vg01/rlvol1 of=/dev/vg02/rlvol1 bs=4096k

It took 23 minutes to complete. Is it normal or increasing the block size will reduce the time? what will be the best bs value to copy faster?

Another issue is that after copy using dd, bdf on destination mount point does not show the correct information. It still shows the old values(before copy). Why is it so? After unmounting and fsck it shows correct informations. Is it necessary to do unmount and fsck after dd copy?

[Michal Kapalka (mikap)]

Hi,

the question is if the size of both LV was the same ???

mikap

[Pete Randall]

Clay Stephenson was the foremost proponent of "lifeboats". Check his comments in this thread:

http://forums13.itrc.hp.com/service/forums/questionanswer.do?admit=109447627+1241613130664+28353475&threadId=1171951


Pete

[Pete Randall]

I forgot to mention that you should take note of Clay's comment about the dirty copy and the requirement to fsck. Yes, you will need to fsck.


Pete

[Steven E. Protter]

Shalom,

bdf never updates until the file handle of the process is closed.

If you did not close it cleanly or stopped dd with a ctrl-break you may need to close the filehandle.

fuser -cu /filesystem_name displays file handles by process id

If you kill the process the file handle will close, bdf will update.

fuser -cuk kills the processes and can kill you session/apps. Be careful with it.

SEP

[Ganesan R]

Hi SEP,

DD is disk block level copying not going to open file handlers which is filesystem level.
So file handlers will not come into picture while dd copying.

I agree that it is dirty copy and needs fsck. is it the reason bdf doesn't show the correct values before fsck?

And what will be best optimal block size to get best speed?

[Bill Hassell · Accepted solution]

> It took 23 minutes to complete. Is it normal or increasing the block size will reduce the time? what will be the best bs value to copy faster?

There is not "best" blocksize because there are hundreds of disk possibilities (SCSI, SAS, fibre arrays, etc) and some will have limits on the maximum blocksize (bigger is generally better). But the speed increase tapers off once you reach 1 MB so that the difference from bs=1024k to bs=4096k is only slightly faster, not 4x faster.

> 16GB in 23 mins ...

That's about 700 MB/min or 11 MB/sec, fairly normal performance for ancient SCSI-2 disks.



> Another issue is that after copy using dd, bdf on destination mount point does not show the correct information. It still shows the old values(before copy). Why is it so? After unmounting and fsck it shows correct informations. Is it necessary to do unmount and fsck after dd copy?

When you copy raw data using dd, absolutely nothing is updated in the running kernel. You are extremely lucky that HP-UX did not crash once you tried to access the copied lvol. The reason is that nothing in the buffer cache concerning this lvol will match. And if this lvol was active while you were copying, you would see a real mess with open files and bad directory entries.

NEVER use dd to copy to a mounted filesystem. It is also bad form to copy a mounted and active filestem. The fact that you were forced to run fsck shows that the original filesystem was not clean at the time of the copy. Again, you were lucky that fsck could put back the pieces.

In the future, if you use dd, always unmount both lvols so you can correctly copy the raw data. Then you can mount the copy without needing fsck and bdf (and df and mount -p, etc) will be accurate.

[Ganesan R]

Thanks to all for clear explanations..

Closing the thread