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

[wesall100200]

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

[cubelee]

那就写不行

[zacharyjia]

盲猜不行

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

[mayx]

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

[wweir]

索引对不上号，没用了

[loading]

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

[mrco]

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

[loading]

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

[n121]

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

# 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]

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

[omph]

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

[watzds]

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

[yidinghe]

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

[monimonipo]

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

[kaneg]

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

[aquariumm]

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

[cabbage]

用 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]

@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 不需要压缩。因为内存带宽足够。压缩反而慢。

[ccav]

在 2t 的盘里建一个 512G 的镜像. COPY 至镜像.

再 2 个同大小之间处理 .

2T 的盘只用了 400G,还余大把空间么.

不熟悉运维业务,不知道这样子可不可行?

[OscarUsingChen]

不行的，至少要先 resize 一下

[shiyouming91]

gparted 缩小一下分区（也有一些命令功效一样比如 resize2fs ），目标盘建立一个一样大的分区 dd 过去。如果需要的话再把分区扩大。