ระบบไฟล์ XFS เสียใน RHEL / CentOS 6.x - ฉันต้องทำอย่างไร


28

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

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

มีปัญหากับ XFS ในระบบ EL6 ที่โผล่ขึ้นมาในเดือนพฤศจิกายน 2012 ฉันสังเกตเห็นว่าเซิร์ฟเวอร์ของฉันแสดงระบบที่โหลดสูงผิดปกติแม้ในขณะที่ไม่ได้ใช้งาน ในกรณีหนึ่งระบบที่ไม่โหลดจะแสดงค่าเฉลี่ยการโหลดอย่างต่อเนื่องที่ 3+ ในคนอื่น ๆ มีการโหลด 1+ ครั้ง จำนวนระบบไฟล์ XFS ที่เมาท์ดูเหมือนจะมีผลต่อความรุนแรงของการเพิ่มโหลด

ระบบมีระบบไฟล์ XFS ที่ใช้งานอยู่สองระบบ โหลดเป็น +2 หลังจากอัปเกรดเป็นเคอร์เนลที่ได้รับผลกระทบ ป้อนคำอธิบายรูปภาพที่นี่

ขุดลึกลงไปผมพบว่าไม่กี่กระทู้บนXFS รายชื่อผู้รับจดหมายที่ชี้ไปยังความถี่ที่เพิ่มขึ้นของxfsaildขั้นตอนการนั่งอยู่ในSTAT Dรัฐ CentOS Bug Tracker ที่สอดคล้องกันและรายการRed Hat Bugzillaจะร่างรายละเอียดเฉพาะของปัญหาและสรุปว่านี่ไม่ใช่ปัญหาด้านประสิทธิภาพ เพียง แต่มีข้อผิดพลาดในการรายงานของการโหลดระบบในเมล็ดใหม่กว่า2.6.32-279.14.1.el6

WTF?!?

ในสถานการณ์แบบครั้งเดียวฉันเข้าใจว่าการรายงานโหลดอาจไม่ใช่เรื่องใหญ่ ลองจัดการกับ NMS ของคุณและเซิร์ฟเวอร์นับร้อยหรือนับพัน! สิ่งนี้ถูกระบุในเดือนพฤศจิกายน 2012ที่เคอร์เนล2.6.32-279.14.1.el6ภายใต้ EL6.3 เมล็ด2.6.32-279.19.1.el6และ2.6.32-279.22.1.el6ได้รับการปล่อยตัวในเดือนต่อมา (ธันวาคม 2012 และกุมภาพันธ์ 2013) โดยไม่มีการเปลี่ยนแปลงพฤติกรรมนี้ มีแม้กระทั่งรุ่นใหม่ของระบบปฏิบัติการตั้งแต่ปัญหานี้ถูกระบุ EL6.4 เปิดตัวและขณะนี้อยู่ในเคอร์เนล2.6.32-358.2.1.el6ซึ่งแสดงพฤติกรรมเดียวกัน

ฉันมีคิวการสร้างระบบใหม่และต้องแก้ไขปัญหาไม่ว่าจะเป็นการล็อกรุ่นเคอร์เนลที่วางจำหน่ายในเดือนพฤศจิกายน 2012 สำหรับรุ่น EL6.3 หรือเพียงแค่ไม่ใช้ XFS, เลือกใช้ext4หรือZFSโดยมีการลงโทษที่รุนแรงสำหรับแอปพลิเคชันที่กำหนดเองที่ระบุที่ทำงานบน แอ็พพลิเคชันที่มีปัญหาต้องอาศัยแอ็ตทริบิวต์ระบบไฟล์ XFS บางตัวเพื่อพิจารณาข้อบกพร่องในการออกแบบแอ็พพลิเคชัน

เมื่อเข้าไปด้านหลังเว็บไซต์ฐานความรู้ที่มีการจ่ายเงินของเรดแฮทรายการจะปรากฏขึ้น:

ค่าเฉลี่ยโหลดสูงจะสังเกตได้หลังจากติดตั้งเคอร์เนล 2.6.32-279.14.1.el6 ค่าเฉลี่ยการโหลดสูงเกิดจาก xfsaild กำลังเข้าสู่สถานะ D สำหรับอุปกรณ์ที่จัดรูปแบบ XFS แต่ละเครื่อง

ขณะนี้ยังไม่มีวิธีแก้ไขปัญหานี้ ขณะนี้กำลังถูกติดตามผ่าน Bugzilla # 883905 วิธีแก้ปัญหาดาวน์เกรดแพคเกจเคอร์เนลที่ติดตั้งเป็นรุ่นต่ำกว่า 2.6.32-279.14.1

(ยกเว้นการลดระดับเมล็ดไม่ใช่ตัวเลือกใน RHEL 6.4 ... )

ดังนั้นเราจึงมีปัญหานี้มากกว่า 4 เดือนโดยไม่มีการแก้ไขที่วางแผนไว้สำหรับระบบปฏิบัติการ EL6.3 หรือ EL6.4 มีการแก้ไขข้อเสนอสำหรับ EL6.5 และมีตัวแก้ไขซอร์สเคอร์เนลอยู่ ... แต่คำถามของฉันคือ:

ในจุดใดที่เหมาะสมที่จะออกจากเมล็ดและแพ็คเกจที่ระบบปฏิบัติการให้มาเมื่อผู้ดูแลอัปสตรีมได้ทำลายฟีเจอร์สำคัญ

Red Hat แนะนำข้อผิดพลาดนี้ พวกเขาควรรวมโปรแกรมแก้ไขเข้าไปในเคอร์เนล errata ข้อดีอย่างหนึ่งของการใช้ระบบปฏิบัติการขององค์กรคือการให้เป้าหมายของแพลตฟอร์มที่สอดคล้องและคาดการณ์ได้ ข้อผิดพลาดนี้ทำให้ระบบหยุดชะงักในระหว่างการผลิตและลดความมั่นใจในการปรับใช้ระบบใหม่ ในขณะที่ฉันสามารถใช้หนึ่งในแพทช์ที่เสนอกับซอร์สโค้ดมันเป็นวิธีที่ปรับขนาดได้? มันจะต้องมีความระมัดระวังในการปรับปรุงให้เป็นปัจจุบันเมื่อมีการเปลี่ยนแปลงระบบปฏิบัติการ

อะไรคือสิ่งที่ถูกต้องย้ายที่นี่?

  • เรารู้ว่าสิ่งนี้อาจแก้ไขได้ แต่ไม่ใช่เมื่อใด
  • การสนับสนุนเคอร์เนลของคุณเองในระบบนิเวศ Red Hat มีชุดของตัวเอง
  • การสนับสนุนการมีสิทธิ์ได้รับผลกระทบคืออะไร
  • ฉันควรวางซ้อนเคอร์เนล EL6.3 ที่ทำงานอยู่ด้านบนของเซิร์ฟเวอร์ EL6.4 ที่เพิ่งสร้างใหม่เพื่อรับฟังก์ชั่น XFS ที่เหมาะสมหรือไม่
  • ฉันควรรอจนกระทั่งเรื่องนี้ได้รับการแก้ไขอย่างเป็นทางการหรือไม่
  • สิ่งนี้พูดอย่างไรเกี่ยวกับการขาดการควบคุมที่เรามีต่อวงจรลินุกซ์ขององค์กร
  • การพึ่งพาระบบไฟล์ XFS สำหรับข้อผิดพลาดในการวางแผน / ออกแบบมานาน

แก้ไข:

แพตช์นี้รวมอยู่ในการเปิดตัวเคอร์เนลCentOSPlusล่าสุด( kernel-2.6.32-358.2.1.el6.centos.plus ) ฉันกำลังทดสอบสิ่งนี้ในระบบ CentOS ของฉัน แต่มันก็ไม่ได้ช่วยอะไรมากสำหรับเซิร์ฟเวอร์ที่ใช้ Red Hat


3
ฉันมักจะอยู่ภายใต้ความเชื่อที่ว่าถ้าคุณใช้ EL6 และให้การสนับสนุน RHEL แล้วความรับผิดชอบของพวกเขาก็คือการแก้ไขให้คุณ?
Tom O'Connor

6
ใช่ ... เรดแฮทจะซ่อมมัน ... ตามตารางเวลาของตัวเอง !! - ปัญหานี้โผล่ขึ้นมาเมื่อปลายปี 2012 มันยังไม่ได้รับการแก้ไข มันไม่ได้กำหนดไว้สำหรับการซ่อมแซมจนการเปิดตัวของ RHEL 6.5 ดังนั้นในทางเทคนิคที่พวกเขาได้รับการการดูแลของมัน ...
ewwhite

ด้วยทัศนคติที่ Red Hat แสดง (อ้างอิงตัวติดตามบั๊ก) ฉันไม่เชื่อว่าพวกเขารบกวน XFS อีกต่อไป เคอร์เนลที่กำหนดเองเหมาะสมที่นี่ แต่จุดจ่ายสำหรับการสนับสนุนคืออะไร บางที CentOS เป็นเส้นทางของคุณ ..
pauska

5
<กลิ่น> ฉันเข้าใจถึงความคับข้องใจของคุณฉันเป็นคนรับผิดชอบต่อสภาพแวดล้อม RHEL / CentOS แบบผสมมาก่อนและ RH ทำให้ยากสำหรับคุณที่จะเก็บของบางอย่างในสต็อกบางครั้งเห็นว่าพวกเขา "เพิกเฉย" ต่อเนื่อง . จากนั้นพวกเขาจะกำหนดเวลาการแก้ไขสำหรับการเปิดตัวรุ่นใหญ่ครั้งต่อไป แต่เนื่องจากพวกเขาไม่สนับสนุนการอัปเกรดเป็นเวอร์ชันหลักต่อไปจึงมีประโยชน์เล็กน้อย เมื่อถึงจุดหนึ่งฉันเลือกที่จะทิ้งเคอร์เนลอย่างเป็นทางการของพวกเขาลงในกล่อง RHEL5 บางอันเพราะฉันต้องเนื่องจากไม่มีคุณสมบัติเฉพาะ </rant>
Adrian Frühwirth

1
@ MartinSchröder SLES ไม่ได้รับความนิยมเป็นพิเศษในสหรัฐอเมริกา แต่อาจเป็นตัวเลือก XFS เองก็ไม่แตก แต่การจัดการของ Red Hat คือ มันคุ้มค่าที่จะพิจารณา
ewwhite

คำตอบ:


14

ในจุดใดที่เหมาะสมที่จะออกจากเมล็ดและแพ็คเกจที่ระบบปฏิบัติการให้มาเมื่อผู้ดูแลอัปสตรีมได้ทำลายฟีเจอร์สำคัญ

"ณ จุดที่เคอร์เนลหรือแพ็คเกจของผู้ขายแตกอย่างน่ากลัวจนส่งผลกระทบต่อธุรกิจของคุณ" คือคำตอบทั่วไปของฉัน (โดยบังเอิญนี่เป็นเรื่องเกี่ยวกับจุดที่ฉันบอกว่าเหมาะสมที่จะเริ่มมองหาหนทางที่จะแยกจากความสัมพันธ์ผู้ขาย) .

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


ใช่ฉันรู้ว่าการหินอ่อนของคุณและการเดินทางกลับบ้านมักจะเป็นเรื่องที่มีราคาแพง - ผู้ขายระบบปฏิบัติการเป็นเรื่องใหญ่โดยเฉพาะอย่างยิ่งในโลกของ Linux ที่รสชาติต่างไปจากเดิมอย่างสิ้นเชิง
ตัวเลือกอื่น ๆ เช่น CentOS โดยรวมก็ไม่น่าสนใจเช่นกัน (เพราะคุณขาดการสนับสนุนและคุณยังคงได้รับรหัสของ RedHat ที่สร้างโดยคนอื่นดังนั้นคุณจึงยังมีข้อบกพร่องนี้อยู่)

น่าเสียดายถ้ามีคนไม่พอ (เช่น "บริษัท ใหญ่ ๆ ") พาหินอ่อนของพวกเขากลับบ้านผู้ขายจะไม่สนใจอะไรมากนักเกี่ยวกับการทำให้คนเมาด้วยการส่งรหัสที่ไม่ดีและไม่แก้ไขมัน


14

นี่คือการแก้ไข ( เงียบ ) โดย Red Hat 23 เมษายน 2013 ในRHEL kernel-2.6.32-358.6.1.el6เป็นส่วนหนึ่งของการอัพเดท 6.4 errata ...


2
20 สัปดาห์หลังจากรายงานข้อผิดพลาด 2 สัปดาห์หลังจากโพสต์ที่นี่คุณคิดว่าอาจจะได้เห็นคำแนะนำทั้งหมดที่บอกว่า "walk" อาจจะเป็นสีแดง
Jasen

อาจจะ? ฉันไม่แน่ใจ.
ewwhite

3

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

มีบทบัญญัติในข้อตกลงการสนับสนุน RHEL สำหรับการทำเช่นนี้ - ISTR คุณถูก จำกัด ที่ 1 หรือ 2 ต่อไตรมาสหรือปี แต่ไม่สามารถจำได้อย่างแน่นอน


ดีมากที่จะรู้!
ewwhite

สิ่งนี้ไม่ถูกต้อง คุณสามารถร้องขอการแก้ไขเร่งจาก Red Hat แต่มีเกณฑ์ที่ต้องดำเนินการเพื่อให้ได้สิ่งนี้และอีกหลายวิธีในการส่งมอบการแก้ไขเร่งที่สนับสนุน หากคุณไปคอมไพล์เคอร์เนลของคุณเองอีกครั้งเรดแฮ็ตนั้นไม่รองรับ
suprjami

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