Jamie Fargen's Weblog

Say you have 1 file that is 10TBytes, like a VM image, that you need to copy between say two nfs file stores (that you don’t control). Your only problem is a single host is only capable of 50MB/sec over a 1Gb/sec network connection. The good news is you have hundreds of hosts all mounting these two nfs filesystems. Maybe you can lash 10-12 hosts together to greatly the reduce the time it takes to copy the file? Then check out scp-tsunami – http://code.google.com/p/scp-tsunami.

Hopefully one day you won’t come upon a server running ESX / Linux that has become unresponsive to regular management tools and view something like this completely filling your console:

sd 7:0:2:0 still retrying after 360s

I knew instantly 7:0:2:0 was a SCSI mapping for host, bus, scsi id, etc, etc. These hosts are using SATA drives and I needed to be able to us hdparm to determine the serial number of the drive for local support to replace.  After digging I came up the command sg_map matched with -x option prints after each active sg device name is displayed there are five digits: <host_number> <bus> <scsi_id> <lun> <scsi_type>.

When I ran sg_map -x this provided me with exactly what I need: /dev/sg2  7 0 2 0  0  /dev/sdc.  You can see that sdc is mapped to SCSI address 7:0:2:0. With this information I was able to use hdparm -i /dev/sdc to extract the serial number of the drive and provide it to local hands and feet support in Germany to swap out the failing hard drive.

A lot of people do backups with rsync and 99% of the time it works pretty well. There is one file type that rsync handles rather poorly and that is sparse files, even though rsyncs documentation indicates that sparse files are handled efficiently it is simply not true. These sparse files are becoming more prominent because they are used to store VM images, like KVM, Xen, even VMWare. So what is a good way to copy them? It turns out that tar is much better at handling sparse files than rsync, it has had support for sparse files for over two decades, and can represent the holes in sparse files more efficiently.

In my testing using Tar instead of Rsync has resulted in cutting the time to backup a sparse file by 8-10 times.

Just pipe tar over ssh and compare your results to rsync:
tar cvzSpf – sparse.file | ssh user@hostname ‘(cd /tmp; tar xzSpf -)’