Copies but with different sizes!!!! 2

[khalidaaa]

Hi all,

i've copied a file system from one machine to the other but discovered that their sizes are different!

That's the destination size:

/dev/image2    114294784  14802928   88%   243415    13% /image2

That's the source server

/dev/image2    114294784   9363360   92%   243428     2% /image2

any body knows why?

I have a feeling that its because of fragments being defragmented while copying!!! That's why i feel is the reason. but i'm not sure

The backup command i used is this:

# rsh edms 'cd /image2;find . -print | backup -iqf -' | restore -xqvpf -

any comments will be appreciated

Regards
Khalid

 

[hirschaj]

Your %Iused is also very different. Are these filesystems both JFS or JFS2, or are they different. Also take a look and see if one is Large File Enabled and the other is not. Very interesting results, I am curious about the reason myself.


Jim Hirschauer

http://www.aixexpert.com

 

[khalidaaa]

oh yeah the first file system is JFS and the new one is JFS2!!!!

so i guess that makes the difference right?

or should i go and check for the large file enabled as you said? how can i check this?

 

[khalidaaa]

oh no large file system is not enabled on the first server

but for the second file system it is jfs2 so i couldn't find this option in there!!!

 

[p5wizard]

There are probably files with all zero-blocks at the source side, these are restored as sparse files at the destination side. (all zero-blocks are simply unallocated on restore, on reading, this is the same effect as reading a block from disk filled with all zeroes. On writing to that as yet unallocated block, LVM will allocate a block on the fly and write to that block.

Google for sparse files for a more in-depth explanation.

If you'll never be updating the files' empty blocks, you've just freed up some disk space. If there's a heavy write to these files, I'd suggest you copy the files over using some other means (rcp, tar) in order to create exact copies of the source system (backup/restore creates sparse file, other copying commands don't). Or: don't start using the free space, because file updates later on might need free blocks!



HTH,

p5wizard

 

[p5wizard]

yes, jfs2 has little overhead as compared to jfs.


HTH,

p5wizard

 

[khalidaaa]

oh thank you very much p5wizard for the explaination but could you please write to me the command if i'm gonna use rcp for example?

 

[khalidaaa]

so what do you think i should do in this case

 

[p5wizard]

I'd use tar.

from the dest server with both /image2 FSs mounted:

# rsh edms tar -cf- /image2 | tar -xf-

But that is only useful if there are sparse files after backup/restore you did earlier and you want to avoid that.

If it's just the jfs/jfs2 difference, I would not worry about it.


HTH,

p5wizard

 

[khalidaaa]

i don't know how would i find out about whether my files contains sparse files

and yes both of the filesystems are different!! one with jfs and the other is with jfs2

and i've used the below command for now as a test for what you've said brother

from the destination server

# rcp -pr edms:/image1/* /image1

and i'm waiting to see the result!!!

before posting this, i created an nfs mount from the old server to the new one and i used the normal cp command to do the copy but it is taking longer time i've been waiting for 2 hours just to copy 10G of data

 

[hirschaj]

Be careful about using the cp command. By default it follows symbolic links instead of just recreating them. You need to make sure you use the -h flag when you use cp.


Jim Hirschauer

http://www.aixexpert.com

 

[khalidaaa]

oh no

Thanks hirschaj even though this made me feel more guilty

Thanks bro

 

[khalidaaa]

oh yeah

you are right guys

when i tried the same copy to a jfs file system the sizes were matching

so i think its because of the different in filesystems type

Thanks all for your support