/ (/dev/sda1)
53 GB / 80 GB · 66%
/home (/dev/sdb1)
74 GB / 200 GB · 37%
/boot/efi (/dev/sda15)
317 MB / 1 GB · 31%
| อุปกรณ์ | ขนาด | รุ่น | สุขภาพ (SMART) | อุณหภูมิ | ชั่วโมงทำงาน | เซกเตอร์ Realloc |
|---|---|---|---|---|---|---|
sda SSD |
80G | QEMU HARDDISK | OK | 36°C | 14,243 | 0 |
sdb SSD |
200G | Samsung SSD 870 | OK | 33°C | 9,221 | 0 |
ปัญหาดิสก์สองอย่างล้มเซิร์ฟเวอร์ได้ และทั้งสองไม่เหมือนกันเลย อย่างช้าคือไดรฟ์ที่เริ่มจะเสีย ซึ่ง SMART มักเห็นล่วงหน้า อย่างเร็วคือระบบไฟล์ที่เต็มขึ้นเรื่อย ๆ แล้วลากบริการล้มไปด้วย ฐานข้อมูลที่เขียนไม่ได้ก็คือฐานข้อมูลที่หยุดทำงาน
หน้านี้ครอบคลุมทั้งสองอย่าง ทั้งการใช้พื้นที่ตามระบบไฟล์ คุณลักษณะ SMART ตามไดรฟ์ และอุณหภูมิ ในบรรดาคุณลักษณะ SMART ที่ทำนายความเสียหายได้จริงมีเพียงจำนวนเซกเตอร์ที่ถูกย้าย เซกเตอร์ที่รออยู่ และเซกเตอร์ที่แก้ไม่ได้แบบออฟไลน์ หากค่าใดค่าหนึ่งขยับออกจากศูนย์ ให้สั่งอะไหล่มาเปลี่ยนแทนที่จะรอการยืนยัน ค่าที่เหลือส่วนใหญ่แกว่งไปมาโดยไม่มีความหมาย
การใช้ inodes จนหมดแสดงแยกไว้ต่างหาก เพราะเมื่อมันเกิดขึ้นแล้วชวนสับสนมาก ดิสก์รายงานว่ามีพื้นที่ว่าง การเขียนกลับล้มเหลว และไม่มีอะไรในจุดที่ควรจะเป็นอธิบายเรื่องนี้ได้ สาเหตุคือไดเรกทอรีที่มีไฟล์เล็ก ๆ นับแสน ทั้งข้อมูลเซสชัน คิวอีเมล แคชที่ไม่เคยหมุนเวียน ซึ่งกินโควตา inodes ที่คงที่ของระบบไฟล์จนหมดโดยแทบไม่แตะความจุเลย
ยังมีปัญหาดิสก์อย่างที่สาม ซึ่งไม่ทำให้อะไรพัง เพียงแต่ทำให้ช้าลง คือไดรฟ์ยุ่งเสียจนกระบวนการต่าง ๆ ต้องเข้าคิวรอ ในตัวเลขเรียกว่า I/O wait และมันแทบไม่เคยสูงขึ้นเอง เบื้องหลังมักมีสิ่งที่ตั้งเวลาไว้ ได้แก่ การสำรองข้อมูลกลางคืน การสร้างดัชนีใหม่ หรือการสแกนเต็มรูปแบบของ ClamAV ทั่วทั้งระบบไฟล์ ถ้าเซิร์ฟเวอร์หนักขึ้นในชั่วโมงเดิมทุกครั้ง ให้มองหาตารางเวลา ไม่ใช่ความเสียหาย