ทำไมการเขียนข้อมูลแบบสุ่มโดยใช้ dd ส่งผลให้เกิดพาร์ติชั่นดิสก์?

ก่อนที่จะรันddคำสั่งคำสั่งจะlsblkส่งคืนผลลัพธ์ด้านล่าง:

NAME              MAJ:MIN  RM   SIZE    RO TYPE  MOUNTPOINT
sda               8:0       0    931.5G  0  disk  

คำสั่งdd if=/dev/urandom of=/dev/sda conv=fsync status=progressถูกเรียกใช้ อุปกรณ์สูญเสียพลังงานและปิดเครื่อง เมื่อไฟฟ้าถูกเรียกคืนคำสั่งlsblkจะส่งคืนเอาต์พุตต่อไปนี้:

NAME              MAJ:MIN     RM   SIZE    RO TYPE  MOUNTPOINT
    sda           8:0          0   931.5G  0  disk 
      sda2        8:2          0   487.5G  0  disk

ความเป็นไปได้หลายประการ:

• Linux สนับสนุนชนิดตารางพาร์ติชันที่แตกต่างกันจำนวนมากบางชนิดใช้เมจิกไบต์น้อยมากและจากนั้นจึงง่ายต่อการระบุข้อมูลแบบสุ่มผิดพลาด (*) [ดังนั้นจึงเป็นไปได้ที่จะสุ่มสร้างตารางพาร์ทิชันที่ค่อนข้าง "ถูกต้อง"

• ตารางชนิดพาร์ติชันบางชนิดมีการสำรองข้อมูลที่ส่วนท้ายของดิสก์เช่นกัน (โดยเฉพาะอย่างยิ่ง GPT) และสามารถรับได้หากการเริ่มต้นของไดรฟ์ถูกแทนที่ด้วยขยะแบบสุ่ม

• อุปกรณ์ทำงานไม่ถูกต้องและถูกตัดการเชื่อมต่อก่อนที่จะเขียนข้อมูลเสร็จหรือส่งคืนข้อมูลเก่าดังนั้นตารางพาร์ติชันจึงมีชีวิตอยู่ บางครั้งสิ่งนี้เกิดขึ้นกับ USB sticks

• ...

(*) สร้างไฟล์ 1,000 ไฟล์ด้วยข้อมูลสุ่มในไฟล์เหล่านั้นและดูว่ามีอะไรออกมาบ้าง:

$ truncate -s 8K {0001..1000}
$ shred -n 1 {0001..1000}
$ file -s {0001..1000} | grep -v data
0099: COM executable for DOS
0300: DOS executable (COM)
0302: TTComp archive, binary, 4K dictionary
0389: Dyalog APL component file 64-bit level 1 journaled checksummed version 192.192
0407: COM executable for DOS
0475: PGP\011Secret Sub-key -
....

เป้าหมายของการทำลายเอกสารแบบสุ่มคือการทำให้ข้อมูลเก่าหายไปได้อย่างดี ไม่มีสัญญาว่าไดรฟ์จะว่างเปล่าไม่ได้ใช้งานในสภาพที่สมบูรณ์หลังจากนั้น

เป็นเรื่องปกติที่จะต้องติดตามด้วยการลบศูนย์เพื่อให้บรรลุ หากคุณใช้ LVM เป็นเรื่องปกติสำหรับ LVM ที่จะลดค่าใช้จ่ายในส่วนแรก ๆ ของ LV ใด ๆ ที่คุณสร้างขึ้นเพื่อไม่ให้ข้อมูลเก่ารบกวน

นอกจากนี้ยังมียูทิลิตี้เฉพาะ ( wipefs) เพื่อกำจัดลายเซ็นไบต์เก่าซึ่งคุณสามารถใช้เพื่อกำจัดเมตาดาต้าระบบไฟล์และพาร์ติชันตาราง

อย่างที่เห็นในที่นี้ MBR (Master Boot Record) นั้นค่อนข้างง่าย https://en.wikipedia.org/wiki/Master_boot_record

เมื่อคุณใช้/dev/urandomคุณสามารถสร้างสิ่งที่ดูเหมือนตารางพาร์ติชัน วิธีการแก้ปัญหาคือการเติมภูมิภาคตารางพาร์ทิชันด้วยศูนย์และใช้dev/urandomสำหรับส่วนที่เหลือ

ลีนุกซ์ยังสนับสนุนรูปแบบดิสก์เพิ่มเติมอื่น ๆ ที่อาจถูกเรียกใช้ทำให้พาร์ทิชัน "ไม่ถูกต้อง" ปรากฏขึ้นเมื่อกรอกข้อมูลแบบสุ่ม

สิ่งที่กำหนดคอลเลกชัน 512 ไบต์ว่าเป็นMaster Boot Recordคือการมีค่า0x55 0xAAในตอนท้าย มีโอกาส 1 ใน 65,536 ใน/dev/urandomการสร้างคุณค่าดังกล่าว: ไม่น่าจะเกินไป แต่สิ่งที่ไม่น่าจะเกิดขึ้นในทำนองเดียวกันเกิดขึ้นตลอดเวลา

(บางตารางพาร์ติชันอื่น ๆ เช่นApple Partition Mapมีลายเซ็นสั้น ๆ คล้ายกันเป็นไปได้ว่าคุณได้สร้างหนึ่งในนั้นแทน)

มีการแบ่งพาร์ติชันบางครั้งก่อนบนดิสก์นั้นหรือไม่ หากดิสก์ใช้ GPT บางที GPT Header รองได้รับการกู้คืนและยังคงมีตารางพาร์ติชันเก่า

https://en.wikipedia.org/wiki/GUID_Partition_Table