☰

dd if=/dev/zeroは、ドライブの内容を変更せずにそのままにしますか？ USBフラッシュドライブが故障しましたか？

tag-icon • tag-icon partition dd gparted flash-memory badblocks
dd if=/dev/zeroは、ドライブの内容を変更せずにそのままにしますか？ USBフラッシュドライブが故障しましたか？

を使用してドライブのすべてのパーティションを破壊できると思いました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を見ると、デバイスが割り当てられていない8 GBとして表示されますが、ドライブは16 GBということです。

私は走りbadblocks -wsv、それが終わっている間それは非常に速かった（数時間ではなく数分）。プラグを抜いて再度挿入した後、/dev/sdcGpartedが「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にあります。

編集2：再起動後、ゼロ化は期待どおりに機能します。私の考えでは、これはオペレーティングシステムの一時的な問題です。まだ何が問題なのか気になりますね。

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スティックにエラーが発生した場合は、新しい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。代わりに、/dev50％RAMサイズの通常のゼロファイルでtmpfsを埋めました。 （tmpfsのサイズ制限を調整する必要があります。2つのtmpfsインスタンスでこれを行うと、RAMがいっぱいになりシステムがクラッシュします。）

これは、デバイスが完全に存在しないか、デバイス名が事前に確認されていないためにデバイス名を誤ってdd入力した場合に発生し/devます10M。結果。

おすすめ記事