我想我可以使用 来破坏驱动器的所有分区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 看到名为“gentoo”的 14.56GB 分区
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
答案1
#the partitions are still there!
至少这部分还是正常的。您必须重新读取分区表来更新分区信息。您可以触发重读
blockdev --rereadpt /dev/sdx
（或者，sfdisk --re-read但该选项已从最新版本的 中删除sfdisk）。
对于其他一切，是的，基于闪存的存储可能会陷入只读模式。由于其他原因也可能会发生奇怪的事情，例如，如果 USB 连接不稳定，设备/dev/sdx可能会被丢弃，并重新检测为/dev/sdy所有写入/dev/sdx进入地狱状态，但我想这会在您的lsblk.
有时会出现有趣的错误消息dmesg，但总而言之...如果您的 USB 记忆棒出现故障，您只需要换一个新的，没有办法解决。
为了完整起见，这里还有这种特殊情况（用户错误）：
# 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，那么您会得到这个令人困惑的结果。