☰

为什么我用 DD 创建的图像大小不同

tag-icon • tag-icon linux ssh raspberry-pi clone dd
为什么我用 DD 创建的图像大小不同

我正在克隆我的 Raspberry PI microSD 卡，以便快速恢复。我使用带有 SSH 的 DD linux 工具，因为它们很难物理访问。

从我的电脑上，我的命令是：ssh root@rpi-one "dd if=/dev/mmcblk0 bs=64K conv=noerror,sync status=progress | gzip --fast " | dd of=~/rpi-clones/$(date %Y-%m-%d)_$(hostname).gz

这个给我最好的结果：18 分钟内 32GB microSD 容量为 3.9GB

我的两颗树莓非常接近：

维护绩效指标 1：

Filesystem      Size  Used Avail Use% Mounted on
/dev/root        29G  3,0G   25G  11% /
devtmpfs        1,8G     0  1,8G   0% /dev
tmpfs           1,9G   16K  1,9G   1% /dev/shm
tmpfs           1,9G  8,8M  1,9G   1% /run
tmpfs           5,0M  4,0K  5,0M   1% /run/lock
tmpfs           1,9G     0  1,9G   0% /sys/fs/cgroup
/dev/mmcblk0p1  253M   49M  204M  20% /boot
log2ram          40M   11M   30M  28% /var/log
tmpfs           384M     0  384M   0% /run/user/1000
tmpfs           384M     0  384M   0% /run/user/0

维护绩效指标 2：

Filesystem      Size  Used Avail Use% Mounted on
/dev/root        29G  3,0G   25G  11% /
devtmpfs        1,8G     0  1,8G   0% /dev
tmpfs           1,9G   16K  1,9G   1% /dev/shm
tmpfs           1,9G  137M  1,8G   8% /run
tmpfs           5,0M  4,0K  5,0M   1% /run/lock
tmpfs           1,9G     0  1,9G   0% /sys/fs/cgroup
/dev/mmcblk0p1  253M   49M  204M  20% /boot
log2ram          40M   13M   28M  32% /var/log
tmpfs           384M     0  384M   0% /run/user/1000
tmpfs           384M     0  384M   0% /run/user/0

所以 ：

RPI 1：1103 秒内 3.9GiB

RPI 2：1337 秒内 6.8GiB

在我的测试开始时，RPI1 和 RPI2 在 3.9GO 时相同，时间也相同。

我想在本地 RPI2 上做一个测试，看看 dd 然后 scp 是否会让我节省时间，但事实并非如此。

所以在我的历史中：

  159  dd if=/dev/mmcblk0 bs=64K status=progress | gzip -9 > /opt/backups/$(date +%Y%m%d\_%H%M%S)\_$(hostname).gz
  160  ll /opt/backups/
  161  rm -rf /opt/backups/

我想知道即使这个测试被删除，是否像扇区这样的东西仍然被“占用”但可用，就像我们用上面的 df -h 命令看到的那样。

我使用 pishrink、e4defrag 等进行了几次测试，结果仍然相同（e4defrag 之后仅增加了 0.4GiB）。

我使用这些 RPI 与 screenly-OSE 来传播图像和视频。

如果您有任何建议...谢谢:)

答案1

图像可能大小相同（如果卡大小相同），但您没有存储图像本身。“我用 DD 创建的图像大小不同”这句话很可能是错误的。压缩档案（哪个是不同的图像大小不同。

您已阅读了整个块设备dd，包括了解相应文件系统中空闲的扇区。空闲扇区不一定包含压缩效果良好的数据，相应文件系统只是将其视为空闲并准备覆盖。请参阅仅从硬盘克隆正在使用的空间， 尤其这个答案其中自由空间故意用零填充以使图像压缩得更好。

如果/opt/backups/物理上是开启的/dev/mmcblk0（我怀疑是这样的），那么您创建/opt/backups/并删除的文件是 RPI2 情况下部分现在可用空间不能很好压缩的最可能原因。

但是你的方法存在一些根本缺陷：

  1. 当块设备上的文件系统已挂载并且可以写入时，复制块设备可能会产生不连贯的图像，相当于全景失败图像（照片）的不同部分来自源（现实）的不同状态。不仅/dev/mmcblk0p1被安装；我怀疑/dev/root相当于/dev/mmcblk0p2或如此，也被安装。除非当时以只读方式安装，否则图像可能会损坏。

    我还怀疑/opt/backups/物理上是/dev/mmcblk0。如果是这样，您尝试将压缩图像存储在此目录中几乎没有机会创建完全连贯的图像。

  2. 不使用conv=sync,noerr除非你真的知道自己在做什么。在你的情况下，这可能是无害的，但有一天你可能会在更不宽容的情况下使用它（例子) 并得到一个完全破碎的图像。

复制块设备的一个好方法是ddrescue，肯定是来自不写入设备的操作系统。我知道您的 Pis 很难物理访问。此外，ddrescue需要图像可查找，因此您无法通过管道传输gzip。无论如何ddrescue都是正确的。

提示：使用 Btrfscompress-force=zlib:9或类似的来存储可搜索的图像；一个独立的改进是ddrescue -S创建一个稀疏图像。

如果你确实需要在正在运行的操作系统中对装有操作系统的设备进行映像，那么你应该将所有相关文件系统重新挂载为只读（sudo mount -o remount,ro …）。这可能并不像你想象的那么容易（这个问题可能有帮助：设备正忙。为什么？）。

答案2

我设法通过 DD 零填充来减小尺寸。

我登录每个 RPI 并启动：

dd if=/dev/zero of=/root/zero 等结束了，rm -f /root/zero

在此之后，我的压缩 DD 图像在 RPI1 和 RPI2 的 861 中为 1.4G :)

相关内容