การทดสอบ SMART ทำอะไรได้บ้างและทำงานอย่างไร


27

man smartctl รัฐ (SNIPPED สำหรับความกะทัดรัด):

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

เปิดใช้งานหรือปิดใช้งานการทดสอบออฟไลน์อัตโนมัติ SMART ซึ่งสแกนไดรฟ์ทุกสี่ชั่วโมงเพื่อหาข้อบกพร่องของดิสก์ คำสั่งนี้สามารถกำหนดได้ระหว่างการทำงานของระบบปกติ

ใครเป็นคนที่ทำการทดสอบ - เฟิร์มแวร์ขับรถ? การทดสอบประเภทใดบ้าง - เฟิร์มแวร์อ่าน / เขียนลงดิสก์ - เกิดอะไรขึ้นกันแน่? ปลอดภัยหรือไม่ที่จะเรียกใช้การทดสอบในขณะที่อยู่ในระบบปฏิบัติการ (linux) หรือสามารถกำหนดเวลาการทดสอบในภายหลัง - วิธีนี้เกิดขึ้นได้อย่างไร - เมื่อคุณรีบูตระบบปฏิบัติการที่พร้อมท์ BIOS ('การทดสอบออฟไลน์') ผลลัพธ์จะปรากฏที่ใด - บันทึก SMART

คำตอบ:


38
  1. เฟิร์มแวร์ของไดรฟ์ทำการทดสอบ

  2. รายละเอียดของการทดสอบสามารถอ่านได้เช่น www.t13.org/Documents/UploadedDocuments/technical/e01137r0.pdf ซึ่งสรุปองค์ประกอบของการทดสอบระยะสั้นและระยะยาวดังนี้:

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

    2. เซ็กเมนต์ค้นหา / เซอร์โวที่ไดรฟ์ทดสอบความสามารถในการค้นหาและเซอร์โวบนแทร็กข้อมูล วิธีการเฉพาะที่ใช้ในการทดสอบนี้เป็นเฉพาะผู้ขายด้วย

    3. ส่วนการอ่าน / ตรวจสอบการสแกนที่ไดรฟ์ทำการอ่านการสแกนของพื้นผิวดิสก์บางส่วน จำนวนและตำแหน่งของพื้นผิวที่สแกนจะขึ้นอยู่กับข้อ จำกัด ด้านเวลาที่เสร็จสมบูรณ์และเป็นข้อมูลเฉพาะของผู้ขาย

    4. เกณฑ์สำหรับการทดสอบตัวเองแบบขยายนั้นเหมือนกับการทดสอบตัวเองแบบสั้นโดยมีข้อยกเว้นสองข้อ: ส่วน (3) ของการทดสอบตัวเองแบบขยายจะเป็นการสแกนแบบอ่าน / ตรวจสอบของพื้นที่ข้อมูลผู้ใช้ทั้งหมดและไม่มี จำกัด เวลาสูงสุดสำหรับไดรฟ์เพื่อทำการทดสอบ

  3. มันปลอดภัยที่จะทำการทดสอบแบบไม่ทำลายในขณะที่ระบบปฏิบัติการกำลังทำงานแม้ว่าจะมีผลกระทบต่อประสิทธิภาพบางอย่าง ในฐานะที่เป็นsmartctlหน้าคนกล่าวว่าสำหรับทั้งสอง-t shortและ-t long,

คำสั่งนี้สามารถกำหนดได้ในการทำงานของระบบปกติ (เว้นแต่จะทำงานในโหมด Captive)

ถ้าคุณเรียกใช้โหมดเชลยด้วย-C, smartctlอนุมานไดรฟ์ที่สามารถติดธุระออกไปยังไม่พร้อม สิ่งนี้ไม่ควรทำบนไดรฟ์ที่ระบบปฏิบัติการใช้อยู่

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

  1. ผลลัพธ์สามารถเห็นได้ในsmartctlผลลัพธ์ นี่คือหนึ่งในการทดสอบการทำงาน:
[ภาพ root @ risby] # smartctl -a / dev / sdb
smartctl 6.4 2015-06-04 r4109 [x86_64-linux-4.1.6-201.fc22.x86_64] (โครงสร้างท้องถิ่น)
ลิขสิทธิ์ (C) 2002-15, Bruce Allen, Christian Franke, www.smartmontools.org
[ ... ]
หมายเลขการแก้ไขโครงสร้างการทดสอบตัวเองของ SMART หมายเลข 1
Num Test_Description สถานะที่เหลือตลอดอายุการใช้งาน (ชั่วโมง) LBA_of_first_error
# 1 ขยายออฟไลน์เสร็จสมบูรณ์โดยไม่มีข้อผิดพลาด 00% 20567 -
# 2 ขยายออฟไลน์เสร็จสมบูรณ์โดยไม่มีข้อผิดพลาด 00% 486 -

โครงสร้างข้อมูลบันทึกการทดสอบตัวเองของ SMART Selective หมายเลขการแก้ไข 0
หมายเหตุ: หมายเลขการแก้ไขที่ไม่ 1 แสดงถึงว่าไม่มีการทดสอบด้วยตนเองแบบเลือกได้
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
   1 0 0 Self_test_in_progress [เหลือ 90%] (0-65535)
   2 0 0 ไม่ใช่การทดสอบ
   3 0 0 ไม่ใช่การทดสอบ
   4 0 0 ไม่ใช่การทดสอบ
   5 0 0 ไม่ใช่การทดสอบ

หมายเหตุการทดสอบที่เสร็จสมบูรณ์สองครั้งก่อนหน้านี้ (ที่การเปิดเครื่อง 486 และ 20567 ชั่วโมงตามลำดับ) และการทำงานปัจจุบันหนึ่ง (เสร็จสมบูรณ์ 10%)


1
นอกจากนี้ถ้าคุณใช้ smartmontools smartd daemon สามารถจัดการทดสอบเป็นระยะโดยไม่ต้องใช้ cronjob นอกจากนี้ยังจัดการการรายงานปัญหาไดรฟ์แม้ว่าอาจต้องการการตรวจสอบเชิงรุก
GnP

8

การใช้ SMART นั้นขึ้นอยู่กับผู้ผลิตบางครั้งมีการบันทึกที่ค่อนข้างกว้างขวางผ่านทางsmart -aคำสั่ง นี่คือสิ่งที่ฉันได้รับจากหนึ่งในไดรฟ์เข้ารหัสตัวเองจากHitachi :

SMART Error Log Version: 1
ATA Error Count: 3

Error 3 occurred at disk power-on lifetime: 2543 hours (105 days + 23 hours)
When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
10 51 08 00 08 00 00  Error: IDNF at LBA = 0x00000800 = 2048

Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
-- -- -- -- -- -- -- --  ----------------  --------------------
60 08 68 00 08 00 40 00      00:00:06.139  READ FPDMA QUEUED
27 00 00 00 00 00 e0 00      00:00:06.126  READ NATIVE MAX ADDRESS EXT
ec 00 00 00 00 00 a0 00      00:00:06.125  IDENTIFY DEVICE
ef 03 46 00 00 00 a0 00      00:00:06.125  SET FEATURES [Set transfer mode]
27 00 00 00 00 00 e0 00      00:00:06.125  READ NATIVE MAX ADDRESS EXT
...

กระดาษสีขาวนี้ให้แสงสว่างบางอย่างเกี่ยวกับรหัสข้อผิดพลาดที่ปรากฏในบันทึก ตัวย่อข้อผิดพลาดทั่วไปคือ:

  • AMNF - ไม่พบเครื่องหมายที่อยู่
  • TONF - ไม่พบแทร็ก 0
  • ABRT - คำสั่งถูกยกเลิก
  • IDNF - ไม่พบ ID ภาค
  • UNC - ข้อมูลไม่ถูกต้อง
  • BBK - เครื่องหมายบล็อกไม่ดี

ในกรณีของฉันข้อผิดพลาด IDNF (ไม่พบ ID) สามารถตรวจสอบย้อนกลับไปยังเหตุการณ์ที่เกิดขึ้นเมื่อมีการเสียบไดรฟ์ผ่านอะแดปเตอร์ USB เป็น SATA และเกิดการ underpowered ซึ่งทำให้ไม่สามารถค้นหาได้อย่างถูกต้อง

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