rsync or rcp on inodes

[Chern Jian Leaw]

HI,

I tried copying filesystems from a different machines. The 2 machines are residing on different NIS domains.

I had used rcp and also rsync to copy the 10 filesystems. Each filesystem is of 12GB-15GB in size. The script is written as below:

#cat fileList.txt
/fs1/circuits/
/fs2/schematics/
/fs3/layoutDesign/
.... (list continues until /fs10/transformation/)

The scripts are invoked on the machine host1.

#cat replicate.sh
#!/bin/sh
for i in `cat fileList.txt`
do
rcp host1:$i host2:$i
done

The script which uses rsync is also similar:
for i in `cat fileList.txt`
do
rsync -avzo $i host2:$i
done

Since the rcp or rsync process hangs frequently while transferring such huge filesystems, I had stopped and restarted the remote copying process.

However, once the copying is complete, I noticed there're duplicated copies of the filesystems transferred from the list.

The source machine host1 does not contain any duplicated copies of the filesystems copied.
I did a ls -lafd on one of the filesystems i.e:
/fs2/schematics/ and found the following:
schematic:
.
..
database
validation_results

schematic^o:
.
..
schematic

This result is similar for other filesystems copied. The duplicated filesystems, which all had the ^o character mysteriously appended to the filesystem names had obviously consumed the / diskspace(root's diskspace is 100%).

Note that the duplicated filesystems mysteriously again contain another filesystem with its name as a sub-directory, e.g:
(results from ls -lafd /fs1/schematic)

schematic^o:
.
..
schematic

All filesystems to be copied from host1 to host2 have had their disk-partitions created, and mounted as:
/fs1/circuits/
/fs2/schematics/
/fs3/layoutDesign/
... (so on ...)

I was wondering if the inodes were affected when the rcp or rsync process were stopped before completion due to the fact that it hanged?

If so, how could the affected inodes affect the filesystem names, by "appending" a ^o at its end? If I'm not mistaken, inodes do not store names of filesystems, do they??

How could the duplicated names arise, based on the inode or data block theory? Or even with rcp or rsync?

Could someone offer any ideas/solutions to this matter?

Thanks.

[harry d brown jr]

(1) rcp -> handles interruptions correctly
(2) rcp nor rsync can copy inodes
(3) rsync is the guilty one here


I would starting looking either for patches to rsync or for a DIFFERENT approach to copying huge amounts of data.

If this is to keep your comapny in business then I suggest you contact HP, EMC, or IBM to assist you in designing an appropriate infrastructure to get the data moved between the two sites. we use emc storage with srdf between our sites.

live free or die
harry

[Chern Jian Leaw]

Harry,

Thanks for the info. However, these remote sites which I mentioned with 2 different NIS domains are separated geographically. It's between the US and Asia.

The rsync process should be the culprit. However, the weird thing is I have forcefully interrupted the sync process in many previous data copying/data synchronization, and such problems did not arise.

Could you kindly explain to me how could such interrupted data copying/data synchronizing process produce a duplicated filesystem?
How is this related to the inode, if any?

Also, if the data had already existed on host2(destination), what are the possible reasons for the data synchronization and copying corrupting the inode, or producing a duplicated copy? In this case, the synchronization/copying is meant to copy missing pieces to the destination.

Could you help me out?

Thanks.