บิตเน่าบนฮาร์ดไดรฟ์เป็นปัญหาจริงหรือไม่? สิ่งที่สามารถทำได้เกี่ยวกับมัน?

32

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

ไดรฟ์จะไม่ถือว่าเป็นเซกเตอร์เสียและการสำรองข้อมูลจะคิดว่าไฟล์นั้นมีการเปลี่ยนแปลง ไม่มีการตรวจสอบที่เกี่ยวข้องกับการตรวจสอบความสมบูรณ์ แม้จะอยู่ในการตั้งค่า RAID ความแตกต่างก็จะถูกตรวจจับ แต่ก็ไม่มีทางรู้ได้ว่าสำเนามิเรอร์ใดถูกต้อง

นี่เป็นปัญหาจริงหรือ และถ้าเป็นเช่นนั้นสิ่งที่สามารถทำได้เกี่ยวกับมันได้หรือไม่ เพื่อนของฉันแนะนำให้ใช้ zfs เป็นวิธีแก้ปัญหา แต่ฉันนึกภาพไม่ออกว่าไฟล์เซิร์ฟเวอร์ของเราอยู่ในที่ทำงานวางโซลาริสและ zfs ไว้ให้ ..

raid hard-drive zfs

— scobi
แหล่งที่มา

1

นี่คือบทความเกี่ยวกับมัน: web.archive.org/web/20090228135946/http://www.sun.com/bigadmin/…

— scobi

ฉันเพิ่งเกิดข้อผิดพลาด SMART ที่ดีบนดิสก์ซีเกทขนาด 200GB เก่า บิตพวกเขามี rotted มากเกินไป :-( มันสั้นหกเดือนของการรับประกัน 5 ปีดังนั้นฉันอาจจะได้รับการเปลี่ยนโดยไม่ต้องยุ่งยากมาก

— ThatGraemeGuy

24

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

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

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

ทั้งสองวิธี: ไม่มีก็ไม่ได้เป็นไปไม่ได้ที่จะตรวจสอบ

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

— NEX
แหล่งที่มา

ตกลงตามวิกิพีเดีย ( en.wikipedia.org/wiki/Error_detection_and_correction ) ฮาร์ดไดรฟ์รุ่นใหม่ใช้ CRC เพื่อตรวจหาข้อผิดพลาดและพยายามกู้คืนโดยใช้การกู้คืนข้อผิดพลาดสไตล์คอมแพคดิสก์ ดีพอสำหรับฉัน

— scobi

1

แต่ถ้า CRC ถูกเก็บไว้ในตำแหน่งเดียวกัน (เซกเตอร์) เหมือนกับข้อมูลสิ่งนี้จะไม่ช่วยในกรณีที่เกิดข้อผิดพลาดทั้งหมด เช่นหากมีข้อมูลข้อผิดพลาดการวางตำแหน่งหัวสามารถเขียนไปยังเซกเตอร์ผิด - แต่ด้วยการตรวจสอบที่ถูกต้อง => คุณจะไม่สามารถตรวจสอบปัญหา นั่นเป็นเหตุผลที่ checksums ใน ZFS ถูกจัดเก็บแยกต่างหากจากข้อมูลที่พวกเขาปกป้อง

— knweiss

ZFS มีการบำรุงรักษาเหมือน Windows หรือไม่ โดยทั่วไปจะเขียนข้อมูลเป็นประจำเพื่อรีเฟรชการเข้ารหัสแม่เหล็ก

— TomTom

ฮาร์ดไดรฟ์สมัยใหม่ไม่ได้ใช้ CRC พวกเขาใช้รหัส Hamming ซึ่งแตกต่างกันมาก มันเป็นสิ่งเดียวกันกับที่หน่วยความจำ ECC ใช้ ข้อผิดพลาดการพลิกแบบหนึ่งบิตสามารถแก้ไขได้ข้อผิดพลาดการพลิกแบบสองบิตสามารถตรวจพบได้ แต่ไม่สามารถแก้ไขได้การพลิกสามบิตขึ้นไปและข้อมูลเสียหายจริง ไม่ว่าในกรณีใด ๆ จะไม่มีการแทนที่ข้อมูลสำรอง ZFS และระบบไฟล์อื่น ๆ ไม่ได้ให้การป้องกันที่ดีกว่ารหัส Hamming บน platters ของไดรฟ์ หากข้อมูลเสียหาย ZFS จะไม่บันทึกคุณ

— โจดี้ลีบรูชอน

@JodyLeeBruchon คุณมีแหล่งที่มาของรหัส Hamming ที่ใช้ส่วนใหญ่ตอนนี้หรือไม่ การรวบรวมข้อมูลที่ฉันทำเมื่อเร็ว ๆ นี้บ่งชี้ว่าผู้ผลิตไดรฟ์ยังคงใช้ CRC-RS 1 2

— Ian Schoonover

16

ใช่มันเป็นปัญหาส่วนใหญ่เป็นขนาดไดรฟ์ขึ้นไป ไดรฟ์ SATA ส่วนใหญ่มีอัตรา URE (ข้อผิดพลาดในการอ่านที่แก้ไขไม่ได้) ที่ 10 ^ 14 หรือทุก ๆ 12TB ของข้อมูลที่อ่านทางสถิติผู้จำหน่ายไดรฟ์กล่าวว่าไดรฟ์จะคืนค่าการอ่านที่ล้มเหลว ไดรฟ์จะยังคงทำงานได้ดีสำหรับส่วนอื่น ๆ ทั้งหมดของไดรฟ์ โดยทั่วไปแล้วไดรฟ์ Enterprise FC & SCSI มีอัตรา URE ที่ 10 ^ 15 (120TB) พร้อมกับไดรฟ์ SATA จำนวนน้อยซึ่งช่วยลด

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

มีหลายวิธีในการป้องกัน: raid6 (หรือเทียบเท่า) ซึ่งป้องกันความล้มเหลวของดิสก์สองตัวที่ดีที่สุดวิธีเพิ่มเติมคือระบบไฟล์ URE ที่รู้ตัวเช่น ZFS โดยใช้กลุ่มการโจมตีที่เล็กลง ข้อ จำกัด (มิรเรอร์ไดรฟ์ขนาดใหญ่หรือไดรฟ์ RAID5 ที่มีขนาดเล็กลง) การขัดดิสก์ & SMART ช่วยได้ แต่ไม่ใช่การป้องกันในตัวเองจริงๆ แต่ใช้นอกเหนือจากหนึ่งในวิธีการข้างต้น

ฉันจัดการแกนหมุนเกือบ 3,000 ลูกในอาร์เรย์และอาร์เรย์นั้นขัดถูไดรฟ์อย่างต่อเนื่องเพื่อค้นหา URE ที่แฝงอยู่ และฉันได้รับกระแสข้อมูลที่ค่อนข้างคงที่ (ทุกครั้งที่พบมันแก้ไขก่อนไดร์ฟล้มเหลวและแจ้งเตือนฉัน) ถ้าฉันใช้ raid5 แทนที่จะเป็น raid6 และไดรฟ์ตัวใดตัวหนึ่งตายไปหมด ... ฉันต้องการ จะมีปัญหาถ้ามันตีบางตำแหน่ง

2

คุณกำลังพูดถึงหน่วยอะไร "10 ^ 14" ไม่ใช่ "rate"

— Jay Sullivan

2

หน่วยจะเป็นเช่น "10 ^ 14 บิตอ่านต่อข้อผิดพลาด" ซึ่งเท่ากับ 12 TB อ่านต่อข้อผิดพลาด

— Jo Liss

2

และแน่นอนว่าโปรดจำไว้ว่าอัตราความผิดพลาดนั้นโดยปกติแล้วจะอ้างอิงในรูปแบบของข้อผิดพลาดแบบเต็มภาคต่อการอ่านบิต ดังนั้นเมื่อผู้ผลิตระบุอัตรา URE ที่ 10 ^ -14 สิ่งที่พวกเขาหมายถึงจริงๆคือความน่าจะเป็นที่ภาคการสุ่มอ่านค่า URE นั้นเท่ากับ 10 ^ -14 และถ้าเป็นเช่นนั้นภาคทั้งหมดกลับมาอ่านไม่ได้ นั่นและความจริงที่ว่านี่คือสถิติ ในโลกแห่งความเป็นจริง UREs มักจะมาเป็นแบทช์

— CVn

9

ฮาร์ดไดรฟ์มักไม่เข้ารหัสบิตข้อมูลเป็นโดเมนแม่เหล็กเดียวผู้ผลิตฮาร์ดไดรฟ์ตระหนักเสมอว่าโดเมนแม่เหล็กสามารถพลิกได้และสร้างการตรวจจับข้อผิดพลาดและการแก้ไขกับไดรฟ์

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

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

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

— Ian Clelland
แหล่งที่มา

2

จริงๆแล้วฉันมีข้อผิดพลาดบิต - เน่า (ในส่วนที่ฉันไม่ได้อ่านมาก) ซึ่งระบบกู้คืนอย่างเงียบ ๆ (ไม่ถูกต้อง) หากอย่างน้อยก็แจ้งให้ฉันทราบว่ามีบิตเน่าฉันสามารถอ่านข้อมูลเพื่อกู้คืนได้ก่อนที่จะไม่สามารถกู้คืนได้ และถ้าไม่สามารถกู้คืนได้ฉันจะสามารถเปรียบเทียบกับฮาร์ดไดรฟ์อื่นได้

— อเล็กซ์

อืมโปรดตรวจสอบข้อมูล HDD SMART ของคุณและ RAM ของระบบเพื่อตรวจสอบว่าไม่มีปัญหาอื่นที่ทำให้เกิดความเสียหาย บิตเน่า / ความเสียหายแบบสุ่มนั้นหายากมากดังนั้นอาจมีบางอย่างเกิดขึ้นกับเครื่องของคุณ

— Brian D.

@BrianD ประเด็นหนึ่งก็คือฉันเก็บฮาร์ดไดรฟ์ไว้ในบรรจุภัณฑ์ที่เป็นฉนวน นี่เป็นสาเหตุที่ทำให้ฮาร์ดไดรฟ์ให้ความร้อนมากกว่า 60 ° C ในขณะที่ทำงานเป็นเวลาหลายวัน เสียงนั้นเป็นเหตุผลที่ถูกต้องหรือไม่ทำไมจึงเกิดบิตเน่า?

— อเล็กซ์

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

— Brian D.

4

ฮาร์ดไดรฟ์สมัยใหม่ (ตั้งแต่ 199x) ไม่เพียง แต่มี checksums แต่ยังรวมถึง ECC ซึ่งสามารถตรวจจับและแก้ไขบิตเน่า "แบบสุ่ม" ได้เล็กน้อย ดู: http://en.wikipedia.org/wiki/SMART

ในทางกลับกันข้อผิดพลาดบางอย่างในเฟิร์มแวร์และไดรเวอร์อุปกรณ์ยังสามารถทำให้ข้อมูลเสียหายได้ในบางกรณี ไดรเวอร์อุปกรณ์รุ่นแรกสำหรับ SATA และ NIC มีข้อมูลเสียหายทั้งใน Linux และ Solaris

ZFS checksums ส่วนใหญ่มุ่งเน้นที่ข้อบกพร่องในซอฟต์แวร์ระดับล่าง ระบบจัดเก็บ / ฐานข้อมูลที่ใหม่กว่าเช่น Hypertable ยังมีการตรวจสอบการอัปเดตทุกครั้งเพื่อป้องกันข้อผิดพลาดในระบบไฟล์ :)

— obecalp
แหล่งที่มา

3

ในทางทฤษฎีนี่เป็นสาเหตุของความกังวล พูดจริงนี่เป็นส่วนหนึ่งของเหตุผลที่เราเก็บสำรองข้อมูลเด็ก / ผู้ปกครอง / ปู่ย่าตายาย การสำรองข้อมูลประจำปีต้องถูกเก็บไว้เป็นเวลาอย่างน้อย 5 ปี IMO และหากคุณมีกรณีของการย้อนกลับไปไกลกว่านั้นไฟล์จะเห็นว่าไม่สำคัญ

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

— Kara Marfia
แหล่งที่มา

1

ฉันไม่เห็นว่าการสำรองข้อมูลลูก / ผู้ปกครอง / ปู่ย่าตายายช่วยได้อย่างไร ไม่มีทางที่จะรู้ได้ว่าระบบนั้นมีบิตที่พลิกเพราะผู้ใช้ตั้งใจจะเปลี่ยนหรือถ้าไดรฟ์ทำมันด้วยตัวเอง ไม่ได้โดยไม่ต้องตรวจสอบบางชนิด

— scobi

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

— Amok

1

การมีการสำรองข้อมูลที่ย้อนกลับไปมากกว่าสัปดาห์ / เดือนจะเพิ่มโอกาสในการมีสำเนาของไฟล์ที่ดี ฉันอาจจะชัดเจนเกี่ยวกับเรื่องนี้

— Kara Marfia

1

ปัญหาคือ: คุณรู้ได้อย่างไรว่าคุณมีสำเนาที่ไม่ดี? และคุณจะรู้ได้อย่างไรว่าสำเนาไหนที่ถูกสำรองเป็นไฟล์ที่ดี? ในวิธีอัตโนมัติ

— scobi

ฉันเคยเห็นบางทีไฟล์ทุก ๆ สองสามปีที่ผ่านมาตกอยู่ในความเสียหายที่อาจเป็นผลมาจากการเน่าเล็กน้อย แต่ฉันอาจจะทุกข์ทรมานจากโรคปลาขนาดเล็ก ฉันสามารถเข้าใจการสำรองข้อมูลไร้ประโยชน์และฉันจะลบหากไม่เหมาะสม มันเป็นเวลาที่ใช้ในการอ่านคำตอบอื่น ๆ โดยไม่คำนึงถึง ;)

— Kara Marfia

2

ใช่มันเป็นปัญหา

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

ตอนนี้ระบบ RAID ก็ทำการ RAID Scrubbing ที่อ่านบล็อกดิสก์เป็นระยะตรวจสอบ parities และแทนที่ถ้าพบว่าบล็อกนั้นไม่ดี

— Matt Rogish
แหล่งที่มา

ระวังความถูกต้องของข้อมูลไม่ใช่คุณสมบัติของระบบ RAID ทั้งหมด

— duffbeer703

1

ด้วยไดรฟ์เทราไบต์มีการแบ่งปันชะตากรรมมากมายและพื้นที่เก็บข้อมูลทางกายภาพของบิตมีขนาดเล็กมากจนปัญหานี้สำคัญมาก ในขณะเดียวกันความน่าจะเป็นที่จะเกิดความล้มเหลวเพิ่มขึ้นอย่างมากกับไดรฟ์เทราไบต์ที่ RAID6 นั้นไม่เพียงพอเว้นแต่คุณจะใส่ไดรฟ์จำนวนมากลงในพูลพูดว่า 8 ขึ้นไป ด้วยจำนวนไดรฟ์ที่น้อยลงจะดีกว่าถ้าใช้แถบมิรเรอร์ aka RAID 10 ทั้ง RAID 6 (raidz2) และ RAID 10 (zpool สร้าง mypool mirror c0t1d0 c0t2d0 มิเรอร์ c0t3d0 c0t4d0) บน ZFS

— Michael Dillon

RAID ไม่สามารถบอกได้ว่าข้อมูลใดดีและมันไม่สามารถแก้ไขข้อผิดพลาดได้ แต่สามารถตรวจจับได้

— Amok

อาละวาด: ไม่ได้เป็นส่วนหนึ่งของ "RAID มาตรฐาน" ต่อ se แต่ระบบขั้นสูง RAID (firmwares ฯลฯ ) ทำอย่างนั้น

— แมตต์ Rogish

@ Michael Dillion - ความน่าเชื่อถือ RAID6 ไม่เพิ่มขึ้นเมื่อคุณเพิ่มจำนวนไดรฟ์ สำหรับข้อมูลทั้งหมดมีเพียงข้อมูลดั้งเดิม + 2 parity การเพิ่มจำนวนไดรฟ์นั้นแย่กว่าสำหรับความน่าเชื่อถือเนื่องจากจะเพิ่มอัตราความล้มเหลวของไดรฟ์ที่เป็นไปได้โดยไม่เพิ่มความซ้ำซ้อนของข้อมูลใด ๆ เหตุผลเดียวที่เพิ่มจำนวนไดรฟ์คือเพิ่มขนาดพื้นที่เก็บข้อมูลที่มีอยู่ของคุณ

— Brian D.

1

ในส่วนที่เกี่ยวกับคำสั่งของ OP เกี่ยวกับ RAID ไม่เข้าใจว่าข้อมูลอะไรดีเทียบกับไม่ดี

คอนโทรลเลอร์ RAID ใช้บิตพาริตี้ (คี่ / คู่) อย่างน้อยที่สุดในแถบข้อมูลทุกแถบ นี่สำหรับทุกสิ่ง; แถบข้อมูลบนดิสก์และแถบข้อมูลแบบพาริตี้ (สำรอง)

ซึ่งหมายความว่าสำหรับ RAID ประเภทใดก็ตามที่มีการสตริปสำหรับความซ้ำซ้อน (RAID 5/6) คอนโทรลเลอร์สามารถบอกได้อย่างถูกต้องว่าแถบข้อมูลดั้งเดิมมีการเปลี่ยนแปลงหรือไม่และหากแถบข้อมูลซ้ำซ้อนมีการเปลี่ยนแปลง

หากคุณแนะนำแถบสำรองที่สองเช่น RAID6 คุณต้องมีแถบข้อมูล 3 ชุดบนไดรฟ์สามตัวที่เสียหายซึ่งทั้งหมดนั้นสอดคล้องกับข้อมูลไฟล์จริงเดียวกัน โปรดจำไว้ว่าระบบ RAID ส่วนใหญ่ใช้แถบข้อมูลที่ค่อนข้างเล็ก (128kb หรือน้อยกว่า) ดังนั้นโอกาสในการ "บิตเน่า" จึงอยู่ในระดับเดียวกันกับไฟล์ขนาดเดียวกันที่ 128kb ซึ่งเป็นไปไม่ได้ในทางปฏิบัติ

— ไบรอัน D.
แหล่งที่มา

0

มันเป็นปัญหาโลกแห่งความจริงใช่ แต่คำถามคือถ้าคุณควรกังวลเกี่ยวกับมันหรือไม่

หากคุณได้รับ hdd ที่เต็มไปด้วยรูปภาพมันอาจไม่คุ้มค่ากับความพยายาม มันเต็มไปด้วยข้อมูลทางวิทยาศาสตร์ที่สำคัญมันอาจเป็นอีกเรื่องหนึ่ง

— Marc Stürmer
แหล่งที่มา