我已经看到各种post讨论使用dd创build驱动器的图像，只存储“使用的数据”。 在提出问题之前，让我们假设一些事情。
假设
问题/问题
使用类似cp和--sparse=always选项与dd一起使用应该产生一个稀疏文件，以便该文件显示为1GB：
cp --sparse=always <(dd if=/dev/sda bs=8M) /mnt/remote/location/disk.img
或者像下面的东西，应该压缩所有零空间：
dd if=/dev/sda1 | gzip -c > /mnt/remote/location/disk.img.gz
那么， 一个稀疏的图像文件对恢复有什么影响呢？ 传输的数据是1GB还是10GB，包括感知空/零空间？ 这显然是评估潜在的networking负载和恢复时间的考虑因素。
附言我知道还有其他的select，如Clonezilla和类似ddrescue将允许恢复能力，但问题是具体关于在上下文中使用dd。
谢谢。
来自微软的这个词是：“在Windows NTFS文件系统中，默认情况下文件不是稀疏的，应用程序或用户需要通过FSCTL_SET_SPARSE控制代码明确标记文件稀疏。 不幸的是，Linux不会通过SMB1标记这些文件。 据说如果你先在Windows端创build稀疏文件（用Cygwin dd if=/dev/zero of=BigFile bs=1M count=1 seek=150000 ），那么你可以继续把它写成稀疏的。 我相信阅读是没有优化的。
使用RHEL6 coreutils-8.4时， cp --sparse=always local_file /mnt/cifs/file_on_cifs不写入稀疏文件。 当读取CIFS文件时，它读取零区域（没有fiemap优化）。 在RHEL6中，备份和恢复都将通过networking传输整个文件。 更好地gzip它。
与Ubuntu 14x上的coreutils-8.25一样的情况。
有一个2014年补丁“添加稀疏文件支持SMB2 / SMB3安装” ，所以希望是稀疏的文件将支持在Windows 8.1和其他平台的挂载的共享。
当您在Linux客户端上挂载某个Linux服务器上的Samba共享时，即使在SMB1上也可以写入稀疏文件。 没有阅读优化。
你可以使用ddrescue和-S选项：
-S --sparse Use sparse writes for outfile. (The blocks of zeros are not actually allocated on disc). May save a lot of disc space in some cases. Not all systems support this. Only regular files can be sparse.
你可以发出类似ddrescue /dev/sda1 /path/to/outfile