如何远程拷贝稀疏文件？

何谓稀疏文件

就是有空洞的文件，空洞并没有实际占用硬盘的物理空间。
Linux中常见的qcow2文件和raw文件，都是稀疏文件。

image.png

上图中的disk size < virtual size 的文件就是sparse file.

how to query sparse file's real size ?

最通用的方式是：

qemu-img info

很多地方写着ls -ls [sparse file] 也能显示出 sparse file's real size , 实测不然，要看使用的是什么文件系统。

xfs 下， ls -al 可以
tmpfs下 ， ls 不行。

 [root@host0 run]# ls -ls disk.raw
20480 -rw-r--r-- 1 root root 53687091200 Nov  9 16:40 disk.raw
[root@host0 run]# ls -alh  disk.raw
-rw-r--r-- 1 root root 50G Nov  9 16:40 disk.raw
[root@host0 run]# qemu-img  info disk.raw
image: disk.raw
file format: raw
virtual size: 50G (53687091200 bytes)
disk size: 20M
[root@host0 run]# mount |grep run 
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
proc on /run/docker/netns/b864c4925b13 type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=52702352k,mode=700)
[root@host0 run]# pwd
/run

不要习惯性的使用scp去拷贝这种稀疏文件

用scp的后果是网络传输大小为该文件的virtual size .

1. 浪费磁盘空间，
2. 如果这个稀疏文件很大的话，scp会很慢。

rsync -S

rsync --sparse sparse-1 sparse-1-copy

资料上说是可以， 但实际测试发现rsync这个参数没有用。

[root@cloud-sz-kolla-b13-01 run]# rsync -avSh disk.raw  /opt/
sending incremental file list
disk.raw
^Crsync error: received SIGINT, Sjavascript:void(0)IGTERM, or SIGHUP (code 20) at rsync.c(551) [sender=3.0.9]

时间太长受不了了，这个参数有毛用啊！！！

通过nfs file system去cp

在目的服务器上配置一个nfs server, 然后在源server上mount , cp 这个文件。

这种方式适合实验环境， nfs server配置比较容易，但如果是生产环境，涉及到防火墙规则。

最佳实践：先tar,再scp

tar命令有一个针对sparse file的参数

tar S
有资料说先gzip或者tar再scp, 实验对比结果如下：

[root@cloud-sz-kolla-b13-01 run]# time tar cSf disk.raw.tar  disk.raw 

real    1m7.728s
user    0m34.368s
sys     0m33.363s

[root@cloud-sz-kolla-b13-01 run]# time gzip -c disk.raw > disk.raw.gz

real    7m33.054s
user    7m27.749s
sys     0m5.322s

[root@cloud-sz-kolla-b13-01 run]# ls -alh disk.raw*
-rw-r--r-- 1 root root 50G Nov  9 16:40 disk.raw
-rw-r--r-- 1 root root 50M Nov  9 16:53 disk.raw.gz
-rw-r--r-- 1 root root 10K Nov  9 16:43 disk.raw.tar

所以tar比gzip 在处理sparse文件上强太多了。

Issues

raw文件拷贝过后文件大小发生变化

[root@cloud-sz-kolla-b13-01 images]# mount |grep repos
10.53.22.9:/vol_yum_repos on /var/ftp/pub/repos type nfs4 (rw,relatime,vers=4.0,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.63.246,local_lock=none,addr=10.53.22.9)
[root@cloud-sz-kolla-b13-01 images]# pwd
/var/ftp/pub/repos/images

[root@cloud-sz-kolla-b13-01 images]# qemu-img  info Atomic-26.raw 
image: Atomic-26.raw
file format: raw
virtual size: 6.0G (6442450944 bytes)
disk size: 1.5G

[root@cloud-sz-kolla-b13-01 images]# cp Fedora-Atomic-26-20171030.0.x86_64.raw.tar  /opt/a/
[root@cloud-sz-kolla-b13-01 images]# 

[root@cloud-sz-kolla-b13-01 a]# qemu-img info Fedora-Atomic-26-20171030.0.x86_64.raw
image: Fedora-Atomic-26-20171030.0.x86_64.raw
file format: raw
virtual size: 6.0G (6442450944 bytes)
disk size: 2.1G

为何从1.5G 变成了2.1G？

• source: 是一个nfs文件系统
• destination: /opt是一个xfs文件系统。