Slides and Notes 15-August-2011

Sunday afternoon I began a copy that ran twice: once with rsync and once with cp. They each copied to a test area on the warehouse.

For the rsync: real time was 441 minutes 20 seconds (55 minutes user time), and for the cp it was 458 minutes 35 seconds (1/2 minute user time). So that looks like a wash. But look again. The actual working time is substantially less. The rsync job started at about 17:00 on Sunday. It started working right away, which is the proper thing for an incremental rsync to do. And then after an hour something happened, and it quit transmitting until just after 22:00. 441 minutes after 17:05 at night is 12:25 in the morning. You can see a dip and then a very fast rise at that point when the cp job kicks in.

You see a large drop at about 1:15 when the regular system drop (see chuma; I think this is the system backup but need to check) kicks in, but it resumes until just after 1:30; and nothing happens until 6:00. Then there's a 2 hour run and the job ends. Total actual copy time for rsync: roughly 3 1/2 hours. For cp roughly 3 hours. Within errors, pretty similar.

The "nothing happens" really means 200K files less than 4K in size


UPDATE

The problem here is lustre. When I copy those same small files to a local disk, the speed is still in the dirt.

Compare the above with copy to the HSM (which includes some large files which copied quickly). The speed below is only slightly slower.


Summary:


Modified 15-August-2011 at 08:50

http://icecube.wisc.edu/~jbellinger/StorHouse/15Aug2011
Previous notes Next notes Main slide directory

Please contact jnbt@hep.physics.wisc.edu if you have trouble accessing the information on this page.