运维题目: 一个 2t 硬盘，只有 400g 数据，将其 dd 对拷到 512G 硬盘是否可行？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

Distributions

› Ubuntu

› Fedora

› CentOS

中文资源站

› 网易开源镜像站

这是一个创建于 2053 天前的主题，其中的信息可能已经有所发展或是发生改变。

今天刷认证书看到这道题，实在想不出是否可行，求各位大佬指点一下，谢谢！

可行

硬盘

运维

指点

26 条回复 • 2019-05-23 16:41:28 +08:00

cubelee

2019-05-18 21:16:23 +08:00 via Android

那就写不行

zacharyjia

2019-05-18 21:18:24 +08:00 via iPhone

盲猜不行

毕竟你对拷的时候不能单挑出有数据的块来进行拷贝

mayx

2019-05-18 21:19:39 +08:00 via Android

那就只拷 512G 的数据呗，剩下的应该也是空字节，忽略就行了

wweir

2019-05-18 21:21:21 +08:00 via Android

索引对不上号，没用了

loading

2019-05-18 21:41:17 +08:00 via Android

可以用 8G 和 4G 的 U 盘做这个实验。

mrco

2019-05-18 21:44:02 +08:00

缩小源硬盘的文件系统（ xfs 的话就不用往后面看了），比如缩小为 500G，然后重新分区，然后 dd 克隆，最后再将目标盘重新分区，扩大至 512G

loading

2019-05-18 21:44:17 +08:00 via Android

我认为不不行的，因为硬盘上的 400G 不是像水一样都放在桶底的，磁盘碎片。
所以限制在 512G 里面可能并没有包含所有真实。
是不是还需要做个实验。

n121

2019-05-18 21:50:45 +08:00

感觉不行，还是动手试了一下。

# dd if=/dev/zero of=32MB bs=1K count=32K
32768+0 records in
32768+0 records out
33554432 bytes (34 MB, 32 MiB) copied, 0.105461 s, 318 MB/s

# mkfs.ext4 32MB

# dd if=32MB of=16M bs=1K count=16K
16384+0 records in
16384+0 records out
16777216 bytes (17 MB, 16 MiB) copied, 0.0500567 s, 335 MB/s

# mkdir mnt; mount 16M mnt
mount: /root/tmp/mnt: wrong fs type, bad option, bad superblock on /dev/loop0, missing codepage or helper program, or other error.

我还复制了一个文件进去测试，就不贴了

为了回复这个问题，验证了下手机号-。-

fhsan

2019-05-18 21:53:09 +08:00

感觉不行，和分区表 GPT、MBR 有关系吗?

omph

2019-05-18 21:57:10 +08:00

基于文件系统的拷贝是可以的，dd 应该不行

watzds

2019-05-18 22:00:48 +08:00 via Android

分区 dd 到另一块硬盘，迁移 ubuntu 试过可以，也许 dd 复制也比较智能，试试呗

yidinghe

2019-05-18 22:02:40 +08:00 via Android

https://unix.stackexchange.com/questions/161859/can-dd-be-used-to-clone-to-a-smaller-hdd-knowing-that-partitions-will-need-ed

monimonipo

2019-05-18 22:03:31 +08:00

绝大部分情况是不行的，极端情况可以

kaneg

2019-05-18 22:09:36 +08:00 via iPhone

除非那 400g 数据都集中排列在前 500g 内

aquariumm

2019-05-18 22:13:03 +08:00 via Android

不可能，先不说超级块对不上，ext4 文件填充是均匀分布的，所以肯定这 400g 数据分布在 2t 的空间中，只 dd 签 512g 只能 d 出来一小部分文件

cabbage

2019-05-18 23:38:26 +08:00 via Android

用 bsdtar/tar 把所有文件打个包比较合适（可以顺便压缩下降低传输时间），用 dd 按区块拷贝不靠谱，因为数据在硬盘上不一定连续。但是非要用 dd 的话，的确可以如 @mrco 所说先把 2TB 硬盘的文件系统缩小到 512GB 以下，dd 克隆到 512GB 的硬盘上以后，再把文件系统扩大占满 512GB。

另外开放下思维的话用 rsync 这种同步备份工具也是相当合适

参考： https://wiki.archlinux.org/index.php/Full_system_backup_with_tar

题外话，单纯 1:1 拷硬盘用 cat 其实比用 dd 更合适，速度也快太多。

比如下边这样拷贝出一份 sda1 的全盘镜像还顺便压缩下：
`cat /dev/sda1 | gzip -c > /media/USBDrive/sda1.iso.gz`

然后克隆到另一台机器的硬盘上：
`gzip -dc /media/USBDrive/sda1.iso.gz | cat - > /dev/sdb1`

就我所知 cat 会自适应使用读写最快的 block 大小，dd 读写往往会很慢，原因是默认的 block size 太小还不能自适应，往往需要手工试验单独指定

ryd994

2019-05-19 02:08:48 +08:00 via Android

@cabbage 以前不推荐用 cat 的原因就是你不知道用的什么 block size，也不知道有没有额外的 padding。额外的 padding 可能影响后面的数据。dd 的 block size 就很确定。

你这样压缩其实压缩不了多少，因为空闲空间不填零，可压缩性很差。要压缩的话先用 zerofree 填充空闲空间。没有 zerofree 的话手动创建一个大文件写满零再删除也行。

然后压缩不建议 gzip，除非是走公网。gzip 压缩率高但 CPU 密集。建议 lzo 随便压一下其实已经够了。特别是经过写零预处理的话。

另外你的命令里 cat 是多余的
gzip -c </dev/sda >/media/USBDrive/sda1.ing.gz
gzip -dc <xx.img.gz >/dev/sda

tar 能加速拷贝是因为 cp 每个文件会 sync 一次，对小文件就很蛋疼。两个 tar 之间用 pipe 连接，pipe 有 buffer 的，而且两个进程各自不 block

tar -c ./ | tar -C /dst/ -xv 不需要压缩。因为内存带宽足够。压缩反而慢。