มันจะปรับปรุงประสิทธิภาพการเขียนเพื่อเติมเต็มไดรฟ์ที่ฟอร์แมตด้วยเลขศูนย์หรือไม่


14

ฉันมีไดรฟ์ 2 TB ซึ่งเต็มไป> 99% ฉันได้ลบพาร์ติชันที่มีและจัดรูปแบบพวกเขาด้วยfidskmkfs.ext4

เท่าที่ฉันรู้ข้อมูลจริงที่อยู่บนไดรฟ์ยังคงมีอยู่ ยังตารางพาร์ติชันถูกกำหนดใหม่

คำถามคือ: มันจะปรับปรุงประสิทธิภาพการเขียนสำหรับการดำเนินการเขียนเพิ่มเติมถ้าดิสก์จะถูกทำความสะอาด ? เมื่อล้างแล้วฉันหมายถึงเติมดิสก์ด้วยศูนย์หรือไม่

สิ่งที่ต้องการ

dd if=/dev/zero of=/dev/sdx bs=1 count=4503599627370496

8
ไม่มีประโยชน์ที่จะเริ่มต้นด้วยศูนย์เพราะมันจะเขียนทับสิ่งใดก็ตามที่อยู่ที่นั่นเพื่อเริ่มต้น
Moab

7
ถ้าเป็น SSD คำตอบก็คือ "ไม่เลย" เพราะ mkfs.ext4 ใช้ TRIM เพื่อทิ้งเนื้อหาของพาร์ติชั่นทั้งหมดดังนั้นการเขียนเลขศูนย์ด้วยตนเองจะทำให้ประสิทธิภาพลดลงเล็กน้อย
user1686

2
@grawity ฉันสงสัยว่ามี SSD ตัวใดที่เปลี่ยนค่าศูนย์ทั้งหมดเป็น TRIM แทนโดยอัตโนมัติ
kasperd

@kasperd: คำถามติดตามที่ดี!
liori

คำถามติดตามที่เป็นไปได้อีกข้อหนึ่ง: หากกล่าวว่าดิสก์คือ VM ที่ติดตั้งอยู่บน SAN ที่มีการจำลองดิสก์ระดับต่ำอาจช่วยได้ (ในกรณีที่ข้อมูลที่ถูกลบในระดับ VM ยกเว้นว่าระบบกำลังใช้ API ที่รับรู้ของ VM บางตัว มันจะเห็น SAN ว่าบล็อกที่ถูกลบทั้งหมดนั้นจำเป็นต้องติดตั้งไว้ในขณะที่การตั้งค่าให้เป็นศูนย์ทั้งหมดจะจบลงด้วยบล็อกที่ทำซ้ำจำนวนมากซึ่งชี้ไปที่สิ่งที่เป็นศูนย์ทั้งหมด)
Foon

คำตอบ:


36

ไม่มันจะไม่ปรับปรุงประสิทธิภาพ

TL; DR: ฮาร์ดดิสก์ไดรฟ์แบบแม่เหล็กหมุนไม่ทำงานอย่างนั้น

ก่อนอื่นเมื่อคุณเขียนข้อมูลใด ๆ ที่ได้รับไปยังไดรฟ์จัดเก็บข้อมูลแม่เหล็กแบบหมุนได้ข้อมูลนั้นจะถูกเปลี่ยนเป็นโดเมนแม่เหล็กที่จริงแล้วอาจดูแตกต่างจากรูปแบบบิตที่คุณกำลังเขียน ซึ่งจะดำเนินการในส่วนหนึ่งเพราะมันง่ายมากที่จะรักษาข้อมูลให้ตรงกันเมื่อรูปแบบการอ่านกลับมาจากแผ่นเสียงมีจำนวนหนึ่งของความแปรปรวนและเช่นสายยาวของ "ศูนย์" หรือ "หนึ่ง" ค่าจะทำให้มันมากยากที่จะรักษาข้อมูลให้ตรงกัน . (คุณได้อ่าน 26,393 บิตหรือ 26,394 บิตแล้วคุณรู้จักขอบเขตระหว่างบิตได้อย่างไร) เทคนิคการทำการแปลงระหว่างบิตข้อมูลคอมพิวเตอร์และชิ้นส่วนที่เก็บได้นั้นมีวิวัฒนาการตลอดเวลา ตัวอย่างเช่นค้นหาการปรับเปลี่ยนความถี่แก้ไข MMFMการบันทึกรหัสกลุ่มและเทคโนโลยีทั่วไปเพิ่มเติมของการเข้ารหัสแบบ จำกัด ระยะเวลาใช้งาน

กระบวนการบันทึกที่เกิดขึ้นจริงเช่นHAMR , PMR , shingledและอื่น ๆ นั้นมีลักษณะคล้ายกันกับสิ่งนี้โดยอธิบายกลไกของวิธีการจัดเก็บโดเมนแม่เหล็กบนสื่อทางกายภาพ

ประการที่สองเมื่อคุณเขียนข้อมูลใหม่ไปยังภาคส่วนโดเมนแม่เหล็กของส่วนที่เกี่ยวข้องของแผ่นเสียงนั้นจะถูกตั้งค่าเป็นค่าที่ต้องการ สิ่งนี้ทำโดยไม่คำนึงว่าโดเมนแม่เหล็กก่อนหน้านี้อยู่ที่ตำแหน่งทางกายภาพนั้น แผ่นเสียงหมุนอยู่ใต้หัวเขียนแล้ว ก่อนอ่านค่าปัจจุบันจากนั้นเขียนค่าใหม่หากและถ้ามันแตกต่างกันจะทำให้การเขียนแต่ละครั้งต้องมีการปฏิวัติสองครั้ง (หรือการเพิ่มหัวสำหรับแต่ละแผ่นเสียง) ทำให้เวลาแฝงการเขียนเพิ่มขึ้นเป็นสองเท่าหรือเพิ่มความซับซ้อนของไดรฟ์ ในทางกลับกันต้นทุนที่เพิ่มขึ้น เนื่องจากปัจจัย จำกัด ในประสิทธิภาพการทำงาน I / O ตามลำดับของฮาร์ดดิสก์คือความเร็วที่แต่ละบิตส่งผ่านภายใต้ส่วนหัวอ่าน / เขียนสิ่งนี้จะไม่ได้รับประโยชน์ใด ๆ กับผู้ใช้ (เป็นกัน ปัจจัย จำกัด ในการสุ่ม I / O คือความเร็วที่หัวอ่าน / เขียนสามารถจัดวางตำแหน่งที่กระบอกสูบที่ต้องการและจากนั้นส่วนที่ต้องการมาถึงใต้หัว เหตุผลหลักที่ทำให้ SSD สามารถทำงานแบบสุ่มใน I / O ได้อย่างรวดเร็วนั้นก็คือการกำจัดปัจจัยทั้งสองอย่างนี้อย่างสมบูรณ์)

ในฐานะที่เป็นแหลมออกโดยJakeGouldเหตุผลหนึ่งว่าทำไมคุณอาจต้องการที่จะ เขียนทับไดรฟ์ที่มีรูปแบบการแก้ไขบางอย่าง (เช่นเลขทั้งหมด) จะเป็นเพื่อให้มั่นใจว่าเศษของข้อมูลที่เก็บไว้ก่อนหน้านี้ไม่สามารถกู้คืนทั้งจงใจหรือบังเอิญ แต่การทำเช่นนั้นจะไม่มีผลต่อประสิทธิภาพของไดรฟ์ในอนาคตเนื่องจากเหตุผลที่กล่าวมาข้างต้น อีกเหตุผลหนึ่งที่อาจกล่าวได้ว่า "ปรับปรุงประสิทธิภาพ" ตามที่lioriชี้ให้เห็นก็คือการช่วยบีบอัดส่วนที่ไม่ได้ใช้ของดิสก์อิมเมจที่จัดเก็บไว้ แต่แม้จะไม่ได้ปรับปรุงประสิทธิภาพของระบบที่ใช้งานอยู่


3
อีกเหตุผลหนึ่งที่ทำให้พาร์ติชัน / ไดรฟ์เป็นศูนย์คือถ้าคุณวางแผนที่จะถ่ายโอนข้อมูลพาร์ติชัน / ไดรฟ์ดิบ (เช่นสำรองทำอิมเมจระบบปฏิบัติการสำหรับหลาย ๆ เครื่องเป็นเทคนิคการย้ายระบบเป็นต้น) ศูนย์บีบอัดได้ดีซึ่งอาจแตกต่างจากเนื้อหาก่อนหน้าใด ๆ ที่เก็บไว้ในไดรฟ์
liori

@liori จุดดี แต่นั่นไม่ใช่สถานการณ์ของผู้ใช้ทั่วไปและมันก็ค่อนข้างไกลจากสิ่งที่ OP อธิบายไว้
CVn

แผ่นดิสก์แบบออพติคอลอาจเป็นแบบไม่หมุนหรือเป็นแบบแม่เหล็ก?
Max Ried

4

คุณพูดแบบนี้:

คำถามคือ: มันจะปรับปรุงประสิทธิภาพการเขียนสำหรับการดำเนินการเขียนเพิ่มเติมถ้าดิสก์จะถูกทำความสะอาด? เมื่อล้างแล้วฉันหมายถึงเติมดิสก์ด้วยศูนย์หรือไม่

ไม่ 100% การเขียนเลขศูนย์ลงดิสก์ไม่เพิ่มประสิทธิภาพ คุณจะทำเช่นนั้นเพื่อทำลายข้อมูล ดังนั้นเมื่อรู้อย่างนั้นคุณพูดอย่างนี้:

เท่าที่ฉันรู้ข้อมูลจริงที่อยู่บนไดรฟ์ยังคงมีอยู่

ใช่แล้ว…ข้อมูลที่เคยมีอยู่บนไดรฟ์ยังคงมีอยู่ในไดรฟ์ในระดับพื้นฐาน ที่กล่าวว่าไม่มีอยู่ในรูปแบบที่ง่ายต่อการเข้าถึงหรือกู้คืน ณ จุดนี้ แต่อาจเป็นเรื่องที่น่ากังวลถ้าคุณกังวลเกี่ยวกับข้อมูลที่ถูกบุกรุกโดยคนที่เต็มใจจะพยายามกู้คืนส่วนของข้อมูลที่ ยังคง

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


การรันเครื่องมืออย่างrecoverไม่นับว่า "ง่าย" หรือไม่? มันจะเปิดขึ้นจำนวนมากและจำนวนของไฟล์บนไดรฟ์เต็มรูปแบบที่ได้รับเพียงแค่mkfs'd
ฮอบส์

0

ของขวัญสองเซ็นต์ของฉันทำให้ทุกคนเป็นประสบการณ์ของตัวเองใช่มันช่วย แต่ด้วยความระมัดระวัง

ฉันมี SSD จำนวนมากและจากการทดสอบของฉันเองฉันขอแนะนำให้เติมเต็มด้วยศูนย์ก่อนที่จะเขียนตารางต้นแบบใหม่และแทนที่พาร์ทิชันลบให้สร้างตารางต้นแบบขึ้นใหม่

ต่อมาฉันจะอธิบายว่าทำไม แต่ขั้นตอนจะเป็นˋddˋ เพื่อเติมทั้ง SSD ใช้ bs = 1M เร็วกว่า bs = 1 และลืมพารามิเตอร์ count เพื่อทำให้มันจบลง (จะทำให้เกิดข้อผิดพลาดที่ไม่มีที่ว่างเมื่อ ถึงจุดจบนั่นคือ spected ดังนั้นไม่ต้องกังวลที่จะเห็นข้อผิดพลาดดังกล่าวจะต้องแสดง); หลังจากเติมเต็มใช้ gparted หรือสิ่งที่คุณต้องการเขียนตารางต้นแบบ (MBR / GPT / etc) ตามต้องการสิ่งนี้จะ 'ตัด' ดิสก์ทั้งหมดจากนั้นสร้างพาร์ติชันที่มีรูปแบบที่ต้องการ ฯลฯ

ทำไมต้องเติมด้วยศูนย์? ประสบการณ์สั้นของฉันคือประสบการณ์ของฉันคือเมื่อฉันเติมด้วยศูนย์ SSD บางตัวที่ให้บล็อกที่อ่านไม่ได้ 2-24 บล็อกได้รับการแก้ไขไม่มีบล็อกอีกต่อไปไม่สามารถเข้าถึงได้อีกต่อไป

ตอนนี้สิ่งแรกที่ฉันทำเมื่อฉันได้รับ SSD ใหม่ก่อนใช้เต็มเติมด้วยศูนย์เพื่อให้แน่ใจว่าฉันจะไม่ประสบข้อผิดพลาดแบบสุ่มทั่วไปของบล็อก 1KiB ที่อ่านไม่ได้อีกครั้ง

ประสบการณ์ของฉัน: การใช้ซอฟต์แวร์เพื่ออ่าน / ทดสอบ SSD ทั้งหมด (มันบอกคุณว่าต้องใช้เวลานานเท่าไหร่ในการอ่านแต่ละส่วน ') ฉันได้รับจำนวนมาก' 512byte ท่อน '(บล็อก 1KiB) ที่ไม่สามารถใช้งานได้และตำแหน่งของพวกเขา การเปลี่ยนแปลงแบบสุ่มและจำนวนความล้มเหลวแตกต่างกันไปจาก 2 ถึง 24 ฯลฯ หลังจากเติมเต็มด้วยศูนย์และสร้างตารางต้นแบบ (ที่ตัดแต่ง vauses) ไม่เซกเตอร์อ่านไม่ได้อีกต่อไป

การทดสอบการชนของฉัน: เมื่อใส่ค่าศูนย์เพื่อกู้คืนจากข้อผิดพลาดดังกล่าวฉันปล่อยให้ SSD หนึ่งตัวใช้หลังจากผ่านไปสองสามชั่วโมงและมีน้อยกว่าหนึ่งเทราไบต์ที่เขียนถึงมัน (120GiB SSD) เสียชีวิตอย่างยิ่ง เข้าถึงได้อีกต่อไปไบออสของเมนบอร์ดไม่สามารถมองเห็นได้เปลือก USB จะหยุดการทำงานเมื่อเข้าถึงดังนั้น Windows จะไม่เห็น Linix fdisk จะไม่เห็น

เป็นการทดสอบแบบ 'ตาย' กับ SSD หลายตัวที่ฉันซื้อในเวลาเดียวกันแบบที่เหมือนกัน ... ทั้งหมดที่ฉันไม่ได้มีค่าเป็นศูนย์จะตายส่วนที่เหลือจะมีการจัดสรรบล็อกจำนวนมาก แต่ไม่มีข้อผิดพลาดที่อ่านไม่ได้อีกต่อไป

แน่นอนข้อสรุปของฉันคือ SSD ทั้งหมดไม่น่าเชื่อถือไม่ว่ายี่ห้อและความจุจะเป็นเช่นไรก็ตาม

ในประสบการณ์ของฉันสิ่งแรกกับพวกเขาคือการบังคับให้พวกเขาเติมเต็มอย่างน้อยหนึ่งครั้งดีกว่าด้วยค่าศูนย์กว่าด้วยการสุ่ม (มันเร็วกว่า)

ยิ่งไปกว่านั้น SSD ส่วนใหญ่จะทำการตัดภายในเมื่อเขียนด้วยศูนย์ (อัลกอริทึมการจำ garbe ฯลฯ )

นอกจากนี้หากคุณกรอกพวกเขาครั้งแรกบล็อกใดก็ตามที่ให้ข้อผิดพลาดในการเขียนได้รับการจัดสรรใหม่ มันจะดีกว่าที่สิ่งนั้นจะเกิดขึ้นโดยไม่มีข้อมูลสำคัญเมื่อค่าศูนย์ที่เขียนถ้าข้อมูลสูญหาย (ทั้งหมดเป็นศูนย์) มันไม่เกี่ยวข้อง แต่ถ้าข้อมูลสำคัญสำหรับระบบปฏิบัติการมันแย่มาก

SSD ส่วนใหญ่ทำการจัดสรรใหม่ แต่การสูญเสียข้อมูลบนบล็อกที่ให้ข้อผิดพลาดในการเขียนมีเพียง 'องค์กร' (มีราคา> 10 €ต่อ GiB) ทำการลองเขียนใหม่หลังจากทำการจัดสรรใหม่อย่างถูกต้อง SSD บางตัวจะคลาย 'ภาค' อื่น ๆ ทั้งหมดลงในบล็อกที่ล้มเหลวเช่น (เช่นการทำ 'ละทิ้ง')

ให้ลองใช้ครั้งแรกหลังจากกรอกข้อมูลครบถ้วนแล้วให้ตรวจสอบข้อมูล SMART เพื่อดูว่ายังสามารถทำการจัดสรรคืนได้มากเพียงใด

มันไม่สำคัญเท่าไหร่ที่จะทำการจัดสรรใหม่ SSD ส่วนใหญ่มาจากผู้ผลิตที่มีบล็อกบางส่วนถูกจัดสรรใหม่แล้วค้นหาหนึ่งที่มีศูนย์น้อยกว่า 1% ดังนั้นที่สำคัญคืออัตราส่วนจัดสรรใหม่เทียบกับการจัดสรรใหม่ในอนาคต

มันเป็นประสบการณ์ของฉันหลังจาก SSD หลายร้อยตัวเสียชีวิตใน 5 5 ปีที่ผ่านมาบางคนเสียชีวิตในชั่วโมงแรกของการใช้งานอื่น ๆ ในหนึ่งสัปดาห์และอื่น ๆ ในหนึ่งเดือน แต่ทั้งหมดที่ฉันทำเช่นนั้นเต็มเติมศูนย์มีชีวิตอยู่สำหรับ 2 ถึง 3 ปีที่มี 13GiB เขียนในแต่ละวัน 3 * 365 * 13 GiB = 13.9TiB เขียนน้อยกว่า manufatures พูด (> 100TiB)

แต่เรื่องความเร็วนั้นส่วนใหญ่ถ้าใช้บน Windows (บน Linux การสตริป 2xHDD LVM2 ที่ดีให้เวลาบูตเท่าเดิม แต่ไม่ล้มเหลวใน> 25 ปี) ดังนั้นการใช้ SSD ด้วยราคา 0.21 €ต่อกิกะไบต์ (120GiB = 25 €) มันคุ้มค่า (สำหรับ Windows) ในหมู่พวกเขาต้องเปลี่ยนหลังจาก 2 หรือ 3 ปี; ฉันหวังว่าเทคโนโลยีจะปรับปรุงความน่าเชื่อถือ

สำหรับ Linux ฉันไม่ต้องการ SSD อีกต่อไปจนกว่าจะมีความน่าเชื่อถือมากกว่า แต่สำหรับพาร์ติชันระบบ Windows (Vista, 7 และ 10) จะต้อง (การบู๊ตลดลงสิบเท่าในบางกรณีด้วย Windows Vista แทนที่จะใช้> 30 นาทีในการบูต บู๊ทบน> 4 นาทีบนแล็ปท็อปเครื่องเก่าของฉัน)

ใช่เติมเต็มด้วยศูนย์เป็นสิ่งที่ต้องให้ประสบการณ์ของฉัน

แต่เฉพาะเมื่อคุณได้รับ SSD และก่อนที่จะใช้เพื่ออะไร

คำแนะนำ: หาก SSD ทำงานได้ไม่ดีนักและระบบปฏิบัติการไม่บอกให้ตัดแต่งทั้งหมดให้ทำการเติมเต็มด้วยศูนย์ในตอนท้ายนั่นคือสิ่งที่อยู่ภายใน SSD เมื่อทิ้งบล็อก นอกจากนี้การบีบเลขศูนย์จะทำให้ระบบอิเล็กทรอนิกส์ชัดเจนนั่นคือสาเหตุที่ช่วยในการกู้คืนบล็อกการอ่านที่ล้มเหลว

และทุกครั้งที่คุณเปลี่ยนข้อมูลลองทำสำเนาโคลน SSD จะแจ้งให้ทราบว่าการเขียนก็โอเคและในส่วนที่ไม่สามารถอ่านได้ (สามารถเขียนได้ตกลง แต่ไม่ได้อ่าน) ระบบปฏิบัติการไม่ได้รับการออกแบบมาเพื่อรองรับสภาพดังกล่าว พวกเขาทั้งหมดคิดว่าถ้า wtite เป็นข้อมูล OK สามารถอ่านได้ อย่าสับสนกับการอ่านข้อมูลที่แตกต่างกับสิ่งที่เขียน

นั่นคือประสบการณ์ของฉันกับ SSD และ HDD สำหรับการบู๊ตและแอพของ Windows ฉันใช้ SSD แต่ allways กับโคลนทำบน HDD ปกติตั้งแต่ SSD ตายในเวลาน้อยกว่า 3 ปี แต่ gor Linux ฉันใช้ 2x หรือ 3x ดี 2.5 "HDD ti รับเวลาที่คล้ายกันกับการใช้งานปกติตามที่ SSD จะให้ แต่ทนนานกว่า (> 25 ปี)

ฉันไม่ต้องจ่าย> 1,000 €สำหรับ SSD 100GiB ที่ทำงานได้ดีเป็นเวลา 10 ปีฉัน preffer จ่าย 25 €สำหรับ 130GiB ทุก 2 หรือ 3 ปี ราคามีความสำคัญ 100 ยูโรต่อปี (องค์กร) เมื่อเทียบกับ 10 ยูโรต่อปี (ยูคอนซัมซุงและอื่น ๆ ) เพียงทำคณิตศาสตร์


การบังคับให้เขียนเซกเตอร์เสียนั้นเป็นวิธีที่เชื่อถือได้ในการ "แก้ไข" พวกเขาตราบใดที่ยังมีเซกเตอร์สำรองอยู่
ลูกปา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.