file size changed using rcp

[John McWilliams_1]

I am trying to copy an oracle data file from 1 server to another using rcp. The original file is approx 1.4 Gb and the copied file is approx 2.3 Gb.
Both systems are HP-UX 10.20 and oracle is shutdown at the time of the copy.

Why is the file size changing ?

Thanks John

[Arunvijai_4]

Hi John,

Check #cksum on both the servers.

-Arun

[spex]

John,

Do the filesystem block sizes differ between the source and destination volume groups?

fstyp -v /dev/vgxx/lvolx |grep f_bsize

PCS

[Bill Hassell · Accepted solution]

Very, very common for database files. The checksums will be the same for both files and they will contain the same data records. The difference is due to a feature of Unix filesystems: sparse files. A sparse file is one which has unwritten records inside the file.

Consider this scenario:

Create a file and write the first record. Then lseek(2) to the one millionth record and write it. Now close the file. The occupied space is two records. But if you copy the file, HP-UX will read all the records including the unwritten ones. The unwritten records contain nulls (zeros) which are supplied by the filesystem code. If you copy the file, the destination will ALWAYS be larger because the unwritten records are sent to the destination. The result is identical files except that one actually occupies all the space while the original doesn't use any space for undefined records.

Depending on the 'emptiness' of the file, the difference could be as much as 100:1 or more.

[Steven E. Protter]

Shalom John,

I've seen it too. Seems to be a feature(bug) of rcp.

I did not encounter this with scp -rp, so I suggest that or tar for the transfer.

tar preservers permissions.

SEP

[Bill Hassell]

One additional note: fbackup is the only backup program which can reduce the size of the destination file. It does this by not writing null records to the destination. This can result in a destination that is at least as small as the original. The corner case is where an application specifically writes a record with all nulls. That record will be skipped by frecover so the destination may be slightly smaller that the original. But both files will checksum the same and applications can't tell the difference.

[A. Clay Stephenson]

If a sparse file is the culprit then ls -l filename will report the same size on both systems but utilities such as bdf which look at filesystem statistics will report very different values. Does ls -l report the same value on both systems? If not, upon what command(s) are you basing your ~1.4GiB and ~2.3GiB values?

[John McWilliams_1]

Thanks for all the help to everyone that replied. The file size was from ll but
du -sk file showed the data size.
We got around the size issue by increasing the filesystem size. I will now expirement with tar and fbackup for future reference.
Cheers John

[John McWilliams_1]

.