ลดเวลาในการลองใหม่ / บล็อกรอไม่ถูกต้องใน Ubuntu

ฉันจะลดเวลารอคอยของ IO และลองอีกครั้งเพื่อให้ระบบปฏิบัติการไม่พยายามเขียนลงในไดรฟ์ที่ล้มเหลวอย่างต่อเนื่องได้อย่างไร

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

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

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

ฉันยังทำการวิจัยแบดเจ็ตและสมาร์ทแวร์และพิจารณาการเขียน pre-check บนไดรฟ์ก่อนเริ่มเขียน

ระบบปฏิบัติการ: Ubuntu Linux (12.04 lts)

— Ryan Sorensen
แหล่งที่มา

มีอะไรผิดปกติกับการตรวจสอบข้อมูลผ่านสมาร์ทเป็นudisks/ smartmonctl? ปัญหา XY แบบคลาสสิกตรงนี้

— Deer Hunter

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

— Ryan Sorensen

คำถามยังไม่ได้รับคำตอบโดยตรงดังนั้นเราจึงไม่ทราบว่าเป็นสิ่งที่เป็นไปได้ใน linux: ฉันจะลดเวลารอคอยของ IO และลองอีกครั้งได้อย่างไร

— imz - Ivan Zakharyaschev

@ imz - IvanZakharyaschev unix.stackexchange.com/a/147304/25985อย่างไรก็ตามเคอร์เนลบันทึกข้อผิดพลาดเหล่านี้ดังนั้นหากสิ่งที่คุณต้องการทำคือจับดิสก์ที่ล้มเหลวก่อนที่จะเกิดปัญหามากขึ้นคุณสามารถสแกนบันทึกระบบได้ที่ ช่วงเวลาปกติ.

— goldilocks

@gol จะเกิดอะไรขึ้นถ้าฉันต้องการจับมันเร็วขึ้น? พระเจ้าไม่ทราบว่าจะต้องใช้เวลานานเท่าใดก่อนที่การดำเนินการของ IO จะปลดบล็อกการรายงานข้อผิดพลาด? (อันที่จริงฉันกำลังพยายามบันทึกข้อมูลจากดิสก์ที่มีข้อผิดพลาด แต่ปัญหาของฉันคล้ายกัน: การทำงานในส่วน "ผิดพลาด" เหล่านี้ทำให้เกิดความล่าช้ามาก ... บางทีฉันอาจทำตามคำแนะนำและคิดค้นวิธีการ ป้อนข้อมูลจากการทดสอบ SMART ddrescueเพื่อไม่ให้แตะต้องส่วนที่รายงานโดย SMART)

— imz - Ivan Zakharyaschev

คำตอบ:

ฉันไม่เคยใช้ tunable นี้มาก่อน แต่คุณอาจต้องการปรับeh_timeout (ข้อผิดพลาดการจัดการหมดเวลา) สำหรับไดรฟ์ที่มีปัญหา:

[root@localhost device]# cat /sys/block/sda/device/eh_timeout
10
[root@localhost device]#

การแสดงด้านบนsdaตั้งไว้ที่ 10 วินาที จากฐานความรู้ Red Hat:

ในการกำหนดค่าหน่วยเก็บข้อมูลบางอย่าง (เช่นการกำหนดค่าที่มี LUN จำนวนมาก) โค้ดการจัดการข้อผิดพลาด SCSI สามารถใช้เวลาจำนวนมากในการออกคำสั่งเช่น TEST UNIT READY ไปยังอุปกรณ์เก็บข้อมูลที่ไม่ตอบสนอง พารามิเตอร์ sysfs ใหม่ eh_timeout ได้ถูกเพิ่มไปยังวัตถุอุปกรณ์ SCSI ซึ่งช่วยให้การกำหนดค่าของค่าการหมดเวลาสำหรับคำสั่ง TEST UNIT READY และ REQUEST SENSE ที่ใช้โดยรหัสการจัดการข้อผิดพลาด SCSI สิ่งนี้จะลดเวลาที่ใช้ในการตรวจสอบอุปกรณ์ที่ไม่ตอบสนองเหล่านี้ ค่าเริ่มต้นของ eh_timeout คือ 10 วินาทีซึ่งเป็นค่าการหมดเวลาที่ใช้ก่อนเพิ่มฟังก์ชันการทำงานนี้

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

ตอนนี้ฉันกำลังตรวจสอบอยู่ Ubuntu ไม่มี eh_timeout แต่มีไฟล์ timeout ซึ่งอาจเหมือนกัน ค่าเริ่มต้นของ Ubuntu ดูเหมือนจะเป็น 30 วินาที จะลดลงเหลือ 5 วินาทีและรายงานกลับ

— Ryan Sorensen

ผลลัพธ์ของคุณคืออะไร

— Bratchley

การตั้งค่าสถานะการหมดเวลาใน 12.04 ไม่ปรากฏว่าทำอะไร ฉันวางแผนที่จะอัพเกรดระบบทดสอบเป็น 14.04 สุดสัปดาห์นี้เพราะมันมี eh_timeout (และหมดเวลาด้วย)

— Ryan Sorensen

@RyanSorensen ดังนั้นคุณได้รับโอกาสที่จะดูว่าพารามิเตอร์นี้ใช้งานได้หรือไม่

— Nat

ฉันไม่สามารถแก้ไขได้eh_timeoutแต่ฉันสามารถเปลี่ยนtimeoutเพื่อให้งานสำเร็จลุล่วงได้

— GuitarPicker

ตรวจสอบ/sys/block/<dev>/statอุปกรณ์ที่คุณสนใจและเปรียบเทียบพารามิเตอร์ที่ 10 (io_ticks)

เช่น, ticks = io_ticks - prev_ticks / seconds_deltatime / 10

นี่เป็นเปอร์เซ็นต์ของเวลาที่ดิสก์ใช้สำหรับรอ io ของดิสก์

เกือบ 100% จะเป็นการตรวจสอบที่คุ้มค่าแน่นอนหรือไม่ก็ฉลาดและเปรียบเทียบกับค่าเฉลี่ยของดิสก์ทั้งหมดและเลือกบนดิสก์ใด ๆ ที่สูงกว่าค่าเฉลี่ย

ดูเอกสารสถิติบล็อกชั้น

เราใช้บางอย่างเช่น Munin และวาดกราฟ คุณสามารถให้มูนินแจ้งเตือนหากมีค่าเกินเกณฑ์เช่น 90% หรือสิ่งที่กราฟแสดงให้เห็นว่าเป็นตัวเลขเตือนภัยที่ดี

เช่นดูกราฟ Munin สองตัวที่แสดงว่า / dev / sdi ต้องการดู ในตัวอย่างนี้ถ้า / dev / sdi เป็นส่วนหนึ่งของอาร์เรย์อาร์เรย์ทั้งหมดจะประสบเพราะมัน

การใช้ดิสก์ต่ออุปกรณ์ - ต่อวัน

การใช้ดิสก์ต่ออุปกรณ์ - รายสัปดาห์

ถ้าคุณดูกราฟสัปดาห์คุณจะเห็นว่า / dev / sdc อาจช้าเช่นกัน

ฉันควรเพิ่ม / dev / sdi ข้างบนไม่ได้เป็นเพียงดิสก์ช้า (อันที่จริงแล้วเป็นดิสก์สีเขียวที่บางคนเพิ่มลงในอาร์เรย์ของดิสก์ระดับเกรดองค์กร) ซึ่งชะลออาร์เรย์ลง ดิสก์ที่ล้มเหลวที่เกิดขึ้นจริงจะโผล่ออกมาเหมือนนิ้วหัวแม่มือเจ็บ

โดยสรุปฉันอาจใช้สคริปต์ถ้ามีเวลา แต่มูนินถ้าฉันต้องการโซลูชันที่รวดเร็วและการเชื่อมต่อกับเซิร์ฟเวอร์นั้นเป็นเรื่องง่าย

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

ขอบคุณ! ข้อมูลเกี่ยวกับสถิติ io ใน Linux นั้นใหม่และน่าจะเป็นประโยชน์ (สำหรับฉัน) ในสถานการณ์เช่นนี้

— imz - Ivan Zakharyaschev