主页 / unix / 问题 / 529066
Accepted
Stonecraft
Asked: 2019-07-09 15:23:11 +0800 CST

dd if=/dev/zero 保持驱动器内容完好？U盘坏了？

  • 772

我以为我可以使用dd if=/dev/zero of=/dev/sdX. 在过去，这一直对我有用，但在这种情况下，它没有按预期工作。

#check the partitions
➜  ~ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   477G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
└─sda2   8:2    0 476.4G  0 part /
sdb      8:16   1  14.6G  0 disk 
├─sdb1   8:17   1   292M  0 part /media/james/Gentoo amd64 20190703T214502Z
└─sdb2   8:18   1   6.3M  0 part /media/james/GENTOOLIVE

#unmount and confirm the drive is still seen.

➜  ~ sudo umount "/media/james/Gentoo amd64 20190703T214502Z"
➜  ~ sudo umount "/media/james/GENTOOLIVE"
➜  ~ lsblk                                                   
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   477G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
└─sda2   8:2    0 476.4G  0 part /
sdb      8:16   1  14.6G  0 disk 
├─sdb1   8:17   1   292M  0 part 
└─sdb2   8:18   1   6.3M  0 part 

#Run dd

➜  ~ sudo dd if=/dev/zero of=/dev/sdb bs=3M                  
dd: error writing '/dev/sdb': No space left on device
2649+0 records in
2648+0 records out
8330620928 bytes (8.3 GB, 7.8 GiB) copied, 5.50879 s, 1.5 GB/s

#the partitions are still there!

➜  ~ lsblk

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   477G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
└─sda2   8:2    0 476.4G  0 part /
sdb      8:16   1  14.6G  0 disk 
├─sdb1   8:17   1   292M  0 part 
└─sdb2   8:18   1   6.3M  0 part 
➜  ~ lsblk

#after unplugging and replugging the drive, the old partition still mounts and still contains files. I was able to open several and read the contents.

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   477G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
└─sda2   8:2    0 476.4G  0 part /
sdb      8:16   1  14.6G  0 disk 
├─sdb1   8:17   1   292M  0 part 
└─sdb2   8:18   1   6.3M  0 part /media/james/GENTOOLIVE

真正让我困惑的是，如果我查看 Gparted，该设备显示为 8GB 未分配，但这是一个 16GB 驱动器。

我跑了badblocks -wsv，它过去了，但速度很快（几分钟而不是几小时）。拔掉再重新插入后，驱动器显示为/dev/sdc，Gparted 看到 14.56GB 分区，名为“gentoo”

Testing with pattern 0xaa: set_o_direct: Invalid argument/0/0 errors)
done                                                 
Reading and comparing: done                                                 
Testing with pattern 0x55: done                                                 
Reading and comparing: done                                                 
Testing with pattern 0xff: done                                                 
Reading and comparing: done                                                 
Testing with pattern 0x00: done                                                 
Reading and comparing: done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)
➜  ~ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   477G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
└─sda2   8:2    0 476.4G  0 part /
sdc      8:32   1  14.6G  0 disk 
├─sdc1   8:33   1   292M  0 part 
└─sdc2   8:34   1   6.3M  0 part

我猜我应该把这个闪存驱动器放到牧场上，但在我看来，这是一个奇怪的事件序列，我很好奇可能是哪种故障导致它（不是真的在寻找修复）。

编辑：这是在 Xubuntu 18.04 上

Edit2：重新启动后，归零按预期工作。我想这只是操作系统的临时问题。不过，我仍然很好奇是什么样的问题。

Edit3：我说得太早了，重启是不够的。我认为dd它正在工作，因为它需要正常的时间，但似乎不是。

➜  ~ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   477G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
└─sda2   8:2    0 476.4G  0 part /
sdb      8:16   1  14.6G  0 disk 
├─sdb1   8:17   1   292M  0 part /media/james/Gentoo amd64 20190703T214502Z
└─sdb2   8:18   1   6.3M  0 part 
➜  ~ sudo dd if=/dev/zero of=/dev/sdb
[sudo] password for james: 
Sorry, try again.
[sudo] password for james: 
dd: writing to '/dev/sdb': No space left on device
30629377+0 records in
30629376+0 records out
15682240512 bytes (16 GB, 15 GiB) copied, 4232.1 s, 3.7 MB/s
➜  ~ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   477G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
└─sda2   8:2    0 476.4G  0 part /
sdb      8:16   1  14.6G  0 disk 
├─sdb1   8:17   1   292M  0 part /media/james/Gentoo amd64 20190703T214502Z
└─sdb2   8:18   1   6.3M  0 part

编辑 4：好的，dd确实有效，但是 lsblk 直到我弹出并放回时才更新。

➜  ~ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0   477G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
└─sda2   8:2    0 476.4G  0 part /
sdb      8:16   1  14.6G  0 disk

编辑 5：我检查了 dmesg 并且有关于磁盘未正确安装的警告。

➜  ~ journalctl --dmesg --since="3 days ago" | grep sdb
Jul 09 19:59:27 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] 30595072 512-byte logical blocks: (15.7 GB/14.6 GiB)
Jul 09 19:59:27 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Write Protect is off
Jul 09 19:59:27 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Mode Sense: 43 00 00 00
Jul 09 19:59:27 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Jul 09 19:59:27 james-Latitude-E7470 kernel:  sdb: sdb1
Jul 09 19:59:27 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Attached SCSI removable disk
Jul 09 19:59:33 james-Latitude-E7470 kernel: FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Jul 10 02:38:38 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] 30629376 512-byte logical blocks: (15.7 GB/14.6 GiB)
Jul 10 02:38:38 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Write Protect is off
Jul 10 02:38:38 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Mode Sense: 43 00 00 00
Jul 10 02:38:38 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Jul 10 02:38:38 james-Latitude-E7470 kernel:  sdb: sdb1 sdb2
Jul 10 02:38:38 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Attached SCSI removable disk
Jul 10 04:12:42 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] 30629376 512-byte logical blocks: (15.7 GB/14.6 GiB)
Jul 10 04:12:42 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Write Protect is off
Jul 10 04:12:42 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Mode Sense: 43 00 00 00
Jul 10 04:12:42 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Jul 10 04:12:42 james-Latitude-E7470 kernel: sd 3:0:0:0: [sdb] Attached SCSI removable disk
partition dd

1 个回答

  1. Best Answer

    #the partitions are still there!

    至少这部分还是正常的。您必须重新读取分区表才能更新分区信息。您可以触发重新阅读

    blockdev --rereadpt /dev/sdx

    （或者sfdisk --re-read，该选项已从最新版本中删除sfdisk）。

    对于其他一切，是的，基于闪存的存储可能无法进入只读模式。奇怪的事情也可能由于其他原因发生，例如，如果 USB 连接不稳定，/dev/sdx设备可能会被丢弃，并重新检测为/dev/sdy所有写入/dev/sdx进入边缘，但我想这会显示在你的lsblk.

    有时会出现有趣的错误消息dmesg，但总而言之……如果您的 U 盘出现故障，您只需要获得一个新的，没有办法解决。

    为了完整起见，这里也有这种特殊情况（用户错误）：

    # dd bs=1M if=/dev/zero of=/dev/sdx
dd: error writing '/dev/sdx': No space left on device
7956+0 records in
7955+0 records out
8341966848 bytes (8.3 GB, 7.8 GiB) copied, 2.08568 s, 4.0 GB/s

    所以。此命令是否写入设备？

    一点也不。我什至没有/dev/sdx. 相反，它/dev用 50% RAM 大小的常规零文件填充了我的 tmpfs。（我真的应该调整我的 tmpfs 大小限制。如果你在两个 tmpfs 实例上这样做，系统会因为 RAM 已满而崩溃。）

    当设备完全丢失或设备名称输入错误时会发生这种情况，因为dd事先根本不检查是否存在，并且如果您的机器有很多 RAM，并且/dev不限于像 一样的合理大小10M，那么您会得到这个令人困惑的结果。

    • 2

相关问题