what reasons could cause the size smaller when copy one fs to another?

[Hanry Zhou]

I used "rsync -xSa /fsa /fsb" tool to copy the entire file system from one to another.
The original file system /fsa contains huge number of files.

The total size of /fsa is about 3.59G, however, as the result /fsb has only size of 2.87G.

I checked two of directories between original one and copied one. Although the number of files under these two directories are the same, but the size of copied one is only 50% of original one. I compared a few files, the size of them are all the same. I can't compare each one of them, because the number of files are about 97,000.

I don't believe there would be anything wrong. But, my questions are following:

1. how do I make sure the original file system is completely copied over?

2. What could cause such differences in size between them? Could it be there are too many number of files causing the issue?

Thanks,

[Steven E. Protter]

I saw the same behavior trying to replicate filesytems containing oracle data and binaries a few years ago.

1) You must check that all the files actually got copied. We discovered that this did not happen and had to use other means for the transfer.

2) If all the files did transfer you may have a problem that all the data in all the files did not transfer. If its a file used for compiling, you won't find out until you compile again.

3) If its none of the above issues, the size differential if small could have to do with the contruction of the fs. If the block/pe size is different, small files will occupy less space, significantly changing over filessystem usage.

Summary: Suspect something is wrong, verify that all is well.

SEP

[Raj D. · Accepted solution]

Hi Hanry ,

You can do this to check and compare fsa and fsb.

1.
# cd /fsa
# find . -type f -xdev -exec ls -l {} \; > fsa.txt
# cat fsa.txt | sort +4 -5nr > /tmp/fsa1.txt


2. cd /fsb
# find . -type f -xdev -exec ls -l {} \; > fsb.txt
# cat fsb.txt | sort +4 -5nr > /tmp/fsb1.txt


3.
# diff /tmp/fsa1.txt /tmp/fsb1.txt

This will show if any difference in files or size in /fsa and /fsb .

Also the file will list files size wise.

Hope this will help ,

Cheers,
Raj.

[James R. Ferguson]

Hi Hanry:

This observation is common. The overall size of a filesystem (directory) may be smaller or larger after a directory-to-directory copy.

Trying to compare the size of directories with 'ls' or 'du' is futile. Blocks once allocated to a directory for file inodes are not deallocated when the file is removed. Thus, it is very common for a directory's size to shrink if it is recreated and its files are reloaded.

If a filesystem contains any "sparse" files, then when they are copied, the space they occupy may be null-filled. Comparing the original file size with its copy with 'ls' will show different sizes. THe copied file will be larger. In fact, this is one way to detect the presence of a sparse file. Comparing the checksums of the two files will yield the same values, regardless of "sparseness".

The only valid way to satisfy yourself that the copy was valid is to compare the checksum of every file represented in the "before" and in the "after" filesystems.

Regards!

...JRF...

[Hanry Zhou]

Raj,

The scripting you suggested is the direction I want to go. However, I have already started the "find..." command for more than an hour, and still running. There are already more than 230,000 files find so far, I dno't know how long it will be continuing.

Also, can you explain a little bit about the sort command you listed there?
Because based on the output file fsa1.txt and fsb1.txt, these files names are not sorted by sequences, so, I'm not sure if diff will help.

JRF,
I have seen size differences when I copy the file systems over, but I never seen the difference will be that big. copied size will be large if there are sparse file? In my case, the size of the copied file system is much smaller.

Stephen,
The file system structure and pe number are the same. both used newfs -F vxfs no other options.

I'm sure with my tool, because the same tool I have used many times

Would too many number of files caused this issue?

[Raj D.]

Hi Hanry ,

The listing will though take a little time , but it will store all the file names. Once it done it will do the sorting based on the file size. The larger file size filename will come top. So you can vi that (fsa1.txt or fsb1.txt ) and check for any missing file you suspect, manualy .

So sorting is not based on their names but their size.
And by running diff hope u can get some difference.

Cheers,
Raj.

[Raj D.]

Hanry ,

If find takes much time , you can try this also:

1)
# cd /fsa
# ls -lR > fsa.txt

2)
# cd /fsb
# ls -lR > fsb.txt

3) sort it, & check with diff.

any luck...



[fyi , find and xdev combination given ,because if you have any other filesystem on the top of this filesystem, so it will not look other filesystem if there is other file system on the top of fsa , fsb directory. ]

Hope ls -lR will work fast.

Cheers,
Raj.

[Hanry Zhou]

Thanks for the quick response.

I did run the command "sort ...", but I'm not sure they are sorted by the size of files. Could you please explain the command to me a little bit more? as for "+4", and "-5nr"?

I have already stopped the command, but will run them again later.

[Raj D.]

Hi Hanry,

check this example , it will be clear:

-------------------------------------------
root@mapsap2 [/usr]
# ls -lR | sort +4 -5nr | more

root@mapsap2 [/usr]
# uname -a
HP-UX mapsap2 B.11.00 U 9000/800 143401347 unlimited-user license

root@mapsap2 [/usr]
# ls -lR | sort +4 -5nr | more
-rwxrwxr-- 1 controlm controlm 242683353 Nov 3 2004 SYBASE.HP11.TAR.Z
-rw-r----- 1 controlm controlm 242532467 Nov 3 2004 HP-UX-11SYBASE12.TAR.Z
-rwxrwxr-- 1 controlm controlm 133367127 Nov 3 2004 HP-UX-10
-rw-r--r-- 1 controlm controlm 83886080 Apr 29 2005 systemprocs.dat
-rwxr-xr-x 1 controlm controlm 51845616 Oct 15 2001 diagserver
-rw-r--r-- 1 root root 48863681 Nov 6 11:00 MHR_fs.csv
-rw-r--r-- 1 controlm controlm 32691294 Jul 14 2002 libsybdb.a
-rw-r--r-- 1 controlm controlm 31457280 Nov 6 11:12 ctrlm_ux.dat
-rw-r--r-- 1 controlm controlm 31457280 Nov 6 11:12 master.dat
-rw-r--r-- 1 controlm controlm 23156112 Jul 14 2002 libct_r.a
-rw-r--r-- 1 controlm controlm 22048412 Jul 14 2002 libct.a
-r--r--r-- 1 bin bin 21265616 Mar 20 2002 libhp-ux.a
-rw-r--r-- 1 root sys 21068537 Jun 9 2003 pushMA.zip
-rwxr-xr-x 1 controlm controlm 20899984 Oct 15 2001 dataserver
---------------------------------------

It sorts the 5th field , that is size filed and place in reverse order , to get bigger file size first ,


2. Have you checked and counted files on each fs . Are they same in number.

you can check this:

a.
# cd /fsa
# ls -lR | sed -n '$='

b.
# cd /fsa
# ls -lR | sed -n '$='

Check if the result of a and b are same or different,

Cheers,
Raj.

[James R. Ferguson]

Hi (again) Hanry:

Some utilities will attempt to handle sparse files and attempt to conserve disk space by not writing null blocks. HP's 'fbackup/frecover' can be controlled this way.

I appears that the '-S' option of 'rsync' offers this ability too and, in fact, you used it.

I found a man pages that notes that '-S' "[tries] to handle sparse files efficiently so they take up less space on the destination." :

http://optics.ph.unimelb.edu.au/help/rsync/rsync.html

I would offer, again, that if you are concerned that something might be amiss, then your best assurance that the source and destination filesystems are 100% the same would be to checksum every file in every directory in both filesystems.

Regards!

...JRF...

[Hanry Zhou]

Raj,

Your script I believe, is working well.

JRF,

I know what you are saying. however, the only thing I was a little confused about is that you said in the first message, the copied file system is supposed to larger. That is I'm confused about, because it makes sense if smaller as the result of using "-S" option.