를 사용하여 드라이브의 모든 파티션을 파괴할 수 있다고 생각했습니다 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/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 크기의 일반 0 파일로 tmpfs를 채웠습니다. (tmpfs 크기 제한을 조정해야 합니다. 두 개의 tmpfs 인스턴스에서 이 작업을 수행하면 RAM이 가득 차서 시스템이 충돌합니다.)
이는 장치가 완전히 없거나 장치 이름을 dd사전에 전혀 확인하지 않았기 때문에 장치 이름을 잘못 입력했을 때 발생하며, 컴퓨터에 RAM이 많고 /dev그 정도의 적당한 크기로 제한되지 않은 경우 10M다음과 같은 오류가 발생합니다. 결과.