ดูเหมือนว่าฉันจะเป็นเซกเตอร์เสียจำนวนมาก นี่คือ SATA M.2 SSD แต่ฉันคิดว่าสิ่งเหล่านั้นดูแลการซ่อนเซกเตอร์เสียโดยที่ระบบปฏิบัติการไม่ต้องยุ่งเกี่ยวกับมัน Ubuntu 20.04 ดูเหมือนจะสามารถนับเซกเตอร์เสียเหล่านี้ได้ แต่ก็ยังประกาศว่าดิสก์นั้น "ตกลง"
ดิสก์ "ตกลง" หรือไม่ ฉันได้รับข้อความแสดงข้อผิดพลาดลึกลับที่ประกาศว่า "Ubuntu 20.04 พบข้อผิดพลาดภายใน" พร้อมรายงาน /var/crash ที่ระบุว่าปัญหาคือ (ตรวจพบโดย?) gnome-control-center ระบบทำงานได้ดีหลังจากเกิดข้อผิดพลาดนี้จนกระทั่งฉันรีบูท สองครั้ง การรีบูตหลังจากข้อผิดพลาดนี้ล้มเหลวโดยสิ้นเชิง ทำให้ต้องติดตั้ง 20.04 ใหม่ทั้งหมด
เหตุใดดิสก์จึงประกาศไดรฟ์ที่สามารถตรวจพบเซกเตอร์เสีย 5439488 "ตกลง" ฉันสันนิษฐานว่าดิสก์กำลังบอกฉันว่า "คุณมี SSD ที่เก่าแล้ว แต่ทุกอย่างอยู่ภายใต้การควบคุมแต่ถ้าจำนวนเซกเตอร์เสียมีส่วนรับผิดชอบต่อความล้มเหลวในการรีบูต (ข้อสันนิษฐานของฉันไม่ใช่ข้อเท็จจริง) เหตุใดดิสก์จึงให้ SSD ผ่านไป
สมมติฐานการทำงานเริ่มต้นของฉันคือ SSD ล้มเหลวอย่างรวดเร็ว การตอบกลับโพสต์นี้แต่เนิ่นๆ (ซึ่งตอนนี้ดูเหมือนจะหายไปแล้ว) แน่ใจว่า 5439488 เสียเซกเตอร์เป็นสัญญาณว่าไดรฟ์จำเป็นต้องเปลี่ยน
ตอนนี้ฉันเชื่อว่าจะผิด
ประการหนึ่ง จำนวนเซกเตอร์เสียยังคงคงที่ที่ 5439488 แม้กระทั่งตอนนี้ หลายวันต่อมา และความคิดของฉันที่ว่าการจัดสรรพื้นที่มากเกินไปเพื่อดูแลเซกเตอร์เสีย (ซึ่งจะเป็นความจริงสำหรับ SSD) เป็นฟังก์ชันที่คอนโทรลเลอร์ SSD มองไม่เห็นระบบปฏิบัติการ ดูเหมือนจะเป็นความเข้าใจผิด ต้องมองเห็นการจัดสรรพื้นที่มากเกินไป เนื่องจากความจุที่ไดรฟ์เผยแพร่ไปทั่วโลกคือ 256GB ฉันเชื่อว่าการจัดสรรพื้นที่มากเกินไปภายในจะเสนอเพียง 240GB เท่านั้น
คำถามเดิมของฉันจบลงที่สิ่งนี้: การจัดสรรพื้นที่มากเกินไปจะปกปิดเซกเตอร์เสียจากระบบปฏิบัติการจนกว่าการจัดสรรพื้นที่มากเกินไปจะหมดลง ซึ่งในกรณีนี้ 5439488 แบดเซกเตอร์จะโอเวอร์โฟลว์ซึ่งกินความจุที่ใช้งานได้ หรือในความเป็นจริงแล้วระบบปฏิบัติการรายงานทุกส่วนที่ล้มเหลว รวมถึงส่วนที่ดูแลโดยการจัดสรรเกิน
อย่างไรก็ตาม ตอนนี้เป็นที่ชัดเจนสำหรับฉันแล้วว่าการจัดสรรพื้นที่มากเกินไป ซึ่งอาจจัดการโดยคอนโทรลเลอร์ SSD (ฉันพูดถูกไหม) กำลังถูกรายงานไปยัง SMART และ Gnome Disks และ GSmartControl จะต้องอ่านสิ่งนี้จาก SMART
การทดสอบสั้นๆ 2 ครั้งและการทดสอบเพิ่มเติมอีก 1 ครั้งรันด้วย GSmartControl, BTW ทั้งหมดนี้เสร็จสิ้นโดยไม่มีข้อผิดพลาด LIke Gnome Disks, GSmartControl รายงานไดรฟ์ว่า "ตกลง"
จากการคำนวณของฉัน เซกเตอร์เสีย (เสถียร) ปัจจุบันมีจำนวนประมาณ 2.8GB SSD ที่มีการจัดสรรพื้นที่มากเกินไปอย่างลับๆ จะประกาศเป็น 240GB โดยมีพื้นที่สำรองประมาณ 16GB เราอยู่ในขอบเขตนั้น
ฉันเริ่มต้นด้วยสมมติฐานว่ามีการเชื่อมต่อระหว่าง 1. จำนวนเซกเตอร์เสียของ Gnome Disks 2. ข้อความ "Ubuntu 20.04 พบข้อผิดพลาดภายใน" และ 3.ความล้มเหลวสองครั้งในการบูต
แต่ฉันอาจจะค่อนข้างผิดเกี่ยวกับเรื่องนี้ ข้อความแสดงข้อผิดพลาดภายในของ Ubuntu ล่าสุดไม่ได้ตามมาด้วยความล้มเหลวในการบู๊ต อย่างที่ฉันพูด จำนวนเซกเตอร์เสียยังคงเสถียร และระบบดูเหมือนจะทำงานได้ดี
ร่างแรกของโพสต์นี้เดิมทีเลิกใช้งานโดยม็อดตามความคิดเห็น ฉันไม่แน่ใจว่าหมายความว่าอย่างไร ใช่ เป็นความคิดเห็นของฉันในขณะนี้หลังจากการทดลองและการไตร่ตรองหลายครั้งว่า SSD ที่มีปัญหานั้นยังอยู่ในสภาพดี ใช้งานได้ และไม่จำเป็นต้องเปลี่ยน (และปัญหาการไม่บู๊ตนั้นก็คือ ไม่ได้เชื่อมต่อ)
คำถามที่สำคัญที่สุดในที่นี้คือ: นี่เป็นการประเมินที่ยุติธรรมหรือไม่ ฉันพลาดอะไรไป
คำถามรอง: ฉันคิดถูกไหมว่า SSD ที่ประกาศความจุเต็มยังคงจัดการกับเซกเตอร์เสียภายใน แต่รายงานไปยัง SMART SSD ที่ขายเป็น เช่น 240GB จัดการกับการจัดสรรพื้นที่เกินขนาด 16GB ภายในโดยไม่ต้องรายงานไปยัง SMART หรือไม่
คำตอบดูเหมือนจะไม่ง่ายที่จะหาได้จากเว็บ ใครก็ได้ช่วยที
-- คริส
ฐานสิบหก(5439488) '0x530000'
มีแนวโน้มว่าตัวเลขนี้เป็นรูปแบบบิต ค่าดิบจำนวนมากที่แสดงโดย smartctl เป็นรูปแบบบิต วิธีตีความมักขึ้นอยู่กับผู้ผลิตที่เกี่ยวข้อง
หากคุณมีเซกเตอร์เสีย 5439488 ฉันจะเปลี่ยนไดรฟ์เพราะมันมีเซกเตอร์เสียจำนวนมาก สำรองและเปลี่ยนไดรฟ์ซึ่งมีโอกาสสูงที่จะล้มเหลวในไม่ช้า
อ่านเซกเตอร์เสียคืออะไร: https://www.howtogeek.com/173463/bad-sectors-explained-why-hard-drives-get-bad-sectors-and-what-you-can-do-about-it/.
หวังว่านี่จะช่วยได้ โจนาธาน สเตดแมน.
เซกเตอร์เสียจำนวนมากไม่จำเป็นต้องเป็นปัญหาเสมอไป แต่ถ้าจำนวนของเซกเตอร์เสียเพิ่มขึ้น (โดยเฉพาะสนิมที่หมุนวน) หรือเซกเตอร์ทดแทนของคุณหมด (ทั้งแบบกลไกหรือแบบ SSD) ความล้มเหลวอาจเกิดขึ้นในไม่ช้า (การปรับระดับการเขียนน่าจะช่วยได้ แต่อาจทำให้สิ่งต่างๆ แย่ลงหากคุณเขียนดิสก์ส่วนใหญ่บ่อยๆ คุณควรใช้การตัดแต่งก่อนที่จะทำการเขียนใหม่ทั้งดิสก์เพื่อลดปัญหานี้)
โปรดจำไว้ว่า SSD มีจำนวนรอบการเขียนที่จำกัดต่อบล็อก การปรับระดับการสึกหรอของ SSD เพื่อพยายามให้จำนวนการเขียนเท่ากันทุกบล็อกเพื่อยืดอายุของไดรฟ์ หากข้อมูล SMART แสดงรายการ ข้อมูลนี้ควรแสดงเป็น Wear_Leveling_Count และตัวเลขภายใต้ค่าปัจจุบันคือเปอร์เซ็นต์ที่เหลืออยู่ เมื่อค่านี้ถึงศูนย์ ไดรฟ์จะตาย โดยอาจไม่ยอมรับการเขียนอีกต่อไป
มีการตอบกลับที่นี่ว่า "ใช่ ต้องเปลี่ยน SSD"
ฉันไม่อยู่ในสถานะที่จะปฏิเสธเรื่องนี้อย่างแน่นอน แต่จากหลักฐานที่ฉันมี ตอนนี้ฉันเชื่อว่านี่ไม่ใช่คำแนะนำที่ดีที่สุด
ตั้งแต่โพสต์สิ่งนี้ครั้งแรกเมื่อสองสัปดาห์ก่อนระบบก็แข็งแกร่งมาก ฉันมีหนึ่งอินสแตนซ์ของข้อความแสดงข้อผิดพลาดภายในของ Ubuntu ที่ฉันพูดถึง แต่ระบบจะรีบูตโดยไม่เกิดปัญหาในภายหลัง และ -- ฉันเชื่ออย่างมาก -- จำนวนเซกเตอร์เสียยังคงอยู่ที่ 5439488 นับตั้งแต่เริ่มต้น
ดังนั้นสมมติฐานการทำงานของฉันจากทั้งหมดนี้คือ: ถ้า Gnome Disks (หรือ SMART จริงๆ) บอกว่าไดรฟ์ของคุณใช้ได้ ก็ถือว่าใช้ได้ อย่าถูกชี้นำโดยจำนวนเซกเตอร์เสียที่สูงอย่างเห็นได้ชัด นั่นเป็นวิธีที่ SSD ทำสิ่งต่างๆ
(ฉันคิดว่ามันจะ -- เอ้อ -- ฉลาดขึ้นถ้าแอปที่ใช้ข้อมูล SMART สามารถแสดงจำนวนเซกเตอร์เสียเป็นเปอร์เซ็นต์การสึกหรอได้ แต่บางที SMART อาจไม่สามารถเข้าถึงยอดรวมที่จัดสรรมากเกินไปได้)
--
คริส
คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา
