How to verify dd copy and possible bs values to use

[Harvindar Singh]

I used the following command to do a copy which took 10 hours and 9 minutes.
ALPHA: # dd if=/dev/vgtower/rttfiles of=/dev/vgdr/rdrfiles bs=8192k

The output of bdf after the copy follows:
/dev/vgtower/ttfiles
631734272 499158032 131540536 79% /home/runtime/is/files

/dev/vgdr/drfiles 631734272 499141016 131557408 79% /dr

My question is why do the "used" and "available" values not match?
/dev/vgtower resides on an XP512 while /dev/vgdr resides on a DS2300 Disk Array with 5x146GB disks.

In the long listing below, please note that the directories 250-0 and 250-4 reside on separate logical volumes and hence would not be copied by dd. Could this explain the discrepancy above even though the directory sizes are identical?

ALPHA:# ll /home/runtime/is/files
total 0
drwxrw-r-- 2 tower tower 96 Aug 20 2001 0-0
drwxrwxrwx 4 tower tower 96 May 27 1999 250-0
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-10
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-12
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-14
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-16
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-18
drwxrwxrwx 3 tower tower 96 Jul 18 1999 250-2
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-20
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-22
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-24
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-26
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-28
drwxr--r-- 3 tower tower 96 Mar 29 11:30 250-350
drwxrwxrwx 4 tower tower 96 Aug 19 1999 250-4
drwxrwxrwx 2 tower tower 96 Jul 29 1999 250-6
drwxrwxrwx 4 tower tower 96 Feb 13 2004 250-8
drwxr-xr-x 2 tower tower 96 Mar 13 2004 lost+found
ALPHA:# ll /dr
total 0
drwxrw-r-- 2 tower tower 96 Aug 20 2001 0-0
drwxrwxrwx 2 root sys 96 Feb 14 2001 250-0
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-10
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-12
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-14
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-16
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-18
drwxrwxrwx 3 tower tower 96 Jul 18 1999 250-2
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-20
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-22
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-24
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-26
drwxrwxrwx 4 tower tower 96 Jul 18 1999 250-28
drwxr--r-- 3 tower tower 96 Mar 29 11:30 250-350
drwxrwxrwx 2 root sys 96 Feb 14 2001 250-4
drwxrwxrwx 2 tower tower 96 Jul 29 1999 250-6
drwxrwxrwx 4 tower tower 96 Feb 13 2004 250-8
drwxr-xr-x 2 tower tower 96 Mar 13 2004 lost+found

I used fsck and mkfs to verify the copy and the results are below. If there is another way, please let me know.
ALPHA:# fsck -F vxfs -n /dev/vgdr/drfiles
pass0 - checking structural files
pass1 - checking inode sanity and blocks
pass2 - checking directory linkage
pass3 - checking reference counts
pass4 - checking resource maps
OK to clear log? (ynq)n
sanity checks/updates have not been completed - restart? (ynq)n

ALPHA:# mkfs -F vxfs -m /dev/vgtower/ttfiles
mkfs -F vxfs -o ninode=unlimited,bsize=8192,version=3,inosize=256,logsize=256,largefiles /dev/vgtower/ttfiles 631734272
ALPHA:/home/runtime/is/import # mkfs -F vxfs -m /dev/vgdr/drfiles
mkfs -F vxfs -o ninode=unlimited,bsize=8192,version=3,inosize=256,logsize=256,largefiles /dev/vgdr/drfiles 631734272

I did testing on the internal disk of a N-Class to get an understanding of the best bs value to use. The results are listed below:
Raw logical volume size = 7,372,800 KB
Command used:
dd if=/dev/vg00/rtlv1 of=/dev/vg00/rtlv2 bs=nnnnk
bs=1024k time=12 min 39 secs
bs=4096k time=11 min 21 secs
bs=8192k time=11 min 9 secs
bs=16384k time=11 min 1 sec

[A. Clay Stephenson · Accepted solution]

Dd copies the filesystem as an image. The statistics should be identical. Were both filesystems unmounted when the dd was done?
If so that had to at least start out identical. I suspect that one or the other filesystems had activity prior to the bdf's being run. I assume that you got no errors on the dd.

[Harvindar Singh]

Both filesystems were un-mounted when dd was run. dd produced the following output ,ie, no errors.
ALPHA:/opt/omni/lbin # time dd if=/dev/vgtower/rttfiles of=/dev/vgdr/rdrfiles bs=8192k
77116+0 records in
77116+0 records out

real 10:09:02.5
user 0.4
sys 3:07.8

I just remembered being pulled away by something else between mounting the filesystems and running bdf. You are right that filesystem activity in the interim caused the difference.
Thank you.

[Bill Hassell]

Just a note about the above directory permissions. I hope they are just tests and contain NO useful data. 777 (drwxrwxrwx) is a very common mistake by new sysadmins to 'fix' some problem. The reality is that not one single file or directory in these 777 directories can be trusted. ANYONE with a login on this computer can (or already has?) trash data files, remove files, rename files, etc. This may have also been caused by the lack of a umask in /etc/profile. No umask means directories are 777 and files are 666, completely open to accidental or purposeful corruption.

[Harvindar Singh]

You are absolutely right - no arguments there.
I inherited the box/environment from a Sys Admin who had a cron jobs that did the following:
chmod -R 777 /pathname
I have doing Sys Admin for 2 plus years now and currently in the process of cleaning up said box/environment.
The directories belong to an application which is due to be upgraded shortly; I was looking to audit and do fixes then.

[Harvindar Singh]

I had done the right thing but an oversight lead me to raise an issue. This was quickly pointed out by responses.