fsck สามารถใช้ปริมาณ 30 TB นานเท่าใด


17

ในกลางเดือนพฤศจิกายน VPS ที่ฉันเช่าจาก บริษัท โฮสติ้งหยุดตอบสนอง เมื่อฉันติดต่อฝ่ายสนับสนุนพวกเขาอธิบายว่าไฟฟ้าดับในดาต้าเซ็นเตอร์ทำให้เกิดการรีบูตและ fsck ในที่สุดฉันถามว่าทำไมมันใช้เวลานานมากและบอกว่าขนาดของปริมาตรคือ 30 TB ครั้งสุดท้ายที่ฉันได้รับการอัปเดตคือในเดือนกุมภาพันธ์และพวกเขาไม่ได้ตอบคำถามล่าสุดของฉัน

ฉันเข้าใจว่า fsck อาจช้ามากสำหรับระบบไฟล์บางระบบ แต่เป็นไปได้ที่ fsck จะใช้เวลา 6 เดือนในปริมาณ 30 TB หรือฉันควรสมมติว่า บริษัท โฮสติ้งแห่งนี้โกหกฉันดังนั้นฉันจะจ่ายบิลต่อไปทุกครั้ง เดือน?


39
พวกเขาอาจโกหกคุณตั้งแต่เริ่มต้น ฉันจะคาดหวังว่าจะใช้เวลาชั่วโมง คุณควรหยุดจ่ายในเดือนธันวาคม
Michael Hampton

15
แม้ว่าพวกเขาจะไม่โกหกก็ตามการเลือกการตั้งค่าซอฟต์แวร์ HW + ที่อาจต้องใช้ FSCK ซึ่งแสดงให้เห็นว่าพวกเขาไม่สามารถทำได้นาน ไม่ว่าด้วยเหตุผลใดก็ตามพวกเขาไม่ได้ให้บริการที่คุณจ่ายไป
Peter Cordes

34
เสียงเหมือนคลัสเตอร์ fsck ตัวจริง!
JMK

2
@JMK ตอนนี้ฉันหวังว่าจะมีวิธีการตั้งค่าสถานะความคิดเห็นสำหรับการทำบุญเพิ่มเติมอาจเพิ่มความฮอลล์ของชื่อเสียง
ท่อ

2
สิ่งที่ @ PeterCordes บอกว่าเป็นประเด็นสำคัญ คุณกำลังจ่ายค่าบริการ คุณเสียใจจริง ๆ ที่ทราบว่าพวกเขากำลังมีปัญหา แต่คุณกำลังเรียกเกี่ยวกับบริการที่คุณจ่ายและไม่ได้รับ
Rob Moir

คำตอบ:


31

fsckความเร็วส่วนใหญ่ขึ้นอยู่กับจำนวนไฟล์และวิธีการแพร่กระจายในไดเรกทอรีที่เกี่ยวข้อง ที่กล่าวว่า 6 เดือนสำหรับ a fsckไร้สาระอย่างสมบูรณ์: มันควรจะเสร็จในเวลาไม่กี่ชั่วโมงโดยเฉพาะอย่างยิ่งถ้าใช้xfsซึ่งมีxfs_repairยูทิลิตี้ที่รวดเร็ว ที่นี่คุณจะพบการfsckวิ่งในระดับหนึ่ง - ทั้งหมดเสร็จสิ้นภายในหนึ่งชั่วโมง (3600 วินาที) ดังนั้นจึงเป็นไปไม่ได้ที่คุณfsckยังทำงานอยู่

อย่างไรก็ตามการสูญเสียอำนาจที่ไม่คาดคิดจะไม่ทำให้เกิดการระเบิดเต็มรูปแบบfsckค่อนข้างเพียงรวดเร็วมาก (บางวินาที) replay วารสาร อย่างไรก็ตามหากไฟล์สำคัญบางไฟล์เกิดความเสียหายระบบปฏิบัติการจะไม่สามารถบูตได้

แต่พวกเขาอาจโกหกคุณ คุณควรหยุดจ่ายทันทีขอคำอธิบายและขอเงินคืนทั้งหมด


8
หากพวกเขากำลังใช้ext2งานแล้วความล้มเหลวของพลังงานจะต้องใช้แบบเต็มfsckและฉันจะไม่แปลกใจหากต้องใช้เวลาหลายวันในปริมาณ 30TB ที่ใช้งานหนัก ในทางกลับกันหากพวกเขากำลังใช้ext2ปริมาณ 30TB นั่นเป็นเหตุผลที่มองหาบริการโฮสติ้ง
Mark

14
ext2 ใช้ตัวนับบล็อกแบบ 32 บิตโดยมีขนาดบล็อกสูงสุด 4096 ไบต์ (เช่น: หน้า) ใน x86 และ x86_64 ซึ่งหมายความว่า ext2 (และ ext3) ถูก จำกัด ไว้ที่ปริมาณ 8TB ดังนั้นไม่ OP ไม่สามารถใช้ ext2 / 3 อย่างไรก็ตามการใช้ใด ๆ ที่ไม่ใช่ระบบแฟ้ม journaled บนไดรฟ์ 30 TB จะเป็นอย่างบ้า
shodanshok

ฉันคิดว่า ext4 fsck อาจจะดีขึ้นเล็กน้อยถ้ามี 30Tb FS ที่มีไฟล์ขนาดเล็กจำนวนมาก ความบ้าคลั่งที่จะสร้างมันขึ้นมาดังนั้นยังคงมีเหตุผลที่จะมองไปที่อื่น
nigel222

7

การคาดเดา: ระบบของพวกเขาใช้ BBU / FBWC-less RAID (หรือแม้แต่ซอฟต์แวร์ RAID) ที่มีแคชการเขียนที่เป็นไปได้ทั้งหมด (รวมถึงเหล่านี้ในฮาร์ดไดรฟ์ตัวเอง) ตั้งค่าที่ก้าวร้าวมากที่สุดเพื่อให้ได้ประสิทธิภาพสูงสุด ไฟฟ้าดับอย่างหนักในการตั้งค่าสามารถปล่อยให้ระบบไฟล์ทำเจอร์นัลในสภาพที่ไม่สามารถเชื่อถือเจอร์นัลและไม่สามารถใช้สำหรับการกู้คืน ปัญหาคือระบบดังกล่าวจัดลำดับใหม่อย่างจริงจังและเลื่อนการเขียนซึ่งหมายความว่ารายการบันทึกประจำวันสามารถเขียนได้ด้วยผลกระทบของการกระทำของข้อมูลที่หายไป ... หรือรายการบันทึกประจำวันจะหายไปกับการกระทำข้อมูลที่เป็นผลสืบเนื่อง

การกู้คืนระบบดังกล่าวจากกรณีไฟดับที่เลวร้ายที่สุดอาจหมายความว่าคุณต้องทำการ fsck / ซ่อมแซม "ช้า" ที่ตรวจสอบโครงสร้างระบบไฟล์ทั้งหมดตามที่เป็นอยู่ซึ่งอาจใช้เวลาหนึ่งหรือสองวันสำหรับ 30TB .... และมัน ไม่น่าเป็นไปได้ที่คุณจะต้องเรียกใช้การซ่อมแซมหลายรอบ เพิ่มไปที่บุคลากรอาจไม่สามารถตรวจสอบเรื่องนี้ได้ตลอดเวลาคุณสามารถลงไปที่ fsck หนึ่งครั้งต่อสัปดาห์ พวกเขาอาจจะยอมแพ้และลืม


1

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

ในกรณีที่เลวร้ายที่สุดมันอาจอ่านดิสก์ทั้งหมด ( เช่นบางอย่างfsck.ext4 -cc /dev/sdaซึ่งทำการทดสอบการเขียนแบบไม่ทำลายในทุกบล็อค) ซึ่งอาจใช้เวลาสองสามวันเป็นเวลา 30 TB หากคุณทราบความเร็วของไดรฟ์คุณสามารถคำนวณขนาด / ความเร็วได้ สำหรับฮาร์ดไดรฟ์สำหรับผู้บริโภคที่มีการคัดลอกประมาณ100 MB / sเพียงไม่กี่ TB อาจใช้เวลาหลายชั่วโมงกว่าที่คนส่วนใหญ่คาดหวัง

หากเป็นเซิร์ฟเวอร์ของคุณคุณอาจมีปัญหาที่บูทแล้วแฮงค์เมื่อfsckถามว่าคุณต้องการแก้ไขข้อผิดพลาดหรือไม่ แต่ผู้ดูแลระบบดาต้าเซ็นเตอร์จะไม่ปล่อยให้fsckค้างอยู่ 6 เดือนในขณะที่ VPS ทั้งหมดออฟไลน์

ดังนั้นพวกเขาจึงโกหกคุณหรือมีความเข้าใจผิดอย่างมาก หรือพวกเขากำลังเรียกใช้ fsck บางเวลาที่ผ่านมาและไม่ได้อัปเดตคุณเกี่ยวกับปัญหาใหม่หลังจากเสร็จสิ้น


4
fsckสำรวจโครงสร้างระบบไฟล์ทั้งหมดซึ่งส่วนใหญ่หมายถึงการดำเนินการสุ่ม i / o ดังนั้นการคำนวณข้างต้นขึ้นอยู่กับอัตราการถ่ายโอนตามลำดับจึงไม่มีประโยชน์
shodanshok

@shodanshok แน่นอนโครงสร้างไฟล์ไม่เกี่ยวข้องในการตรวจสอบไดรฟ์ทั่วไปตามที่ฉันเพิ่งอธิบายในคำตอบของฉัน
Overmind

@ shodanshok สมมติฐานที่เลวร้ายที่สุดของฉันขึ้นอยู่กับ fsck ที่กว้างขวางมาก ตัวอย่างเช่น xfs ทั่วไป fsck ไม่ได้ทำอะไรมาก ext2 มีการตรวจสอบที่ใช้งานมานานและสแกนดิสต์ MS-DOS รุ่นเก่ามีการทดสอบการอ่าน - เขียนบนฮาร์ดไดรฟ์แต่ละบล็อคเมื่อใช้งานในโหมดเต็ม ดังนั้นคุณมีขอบเขตบนที่ขนาดของดิสก์
อัลโล

1
@Overmind และคุณตอบไม่เกี่ยวข้องกับคำถามที่เกี่ยวกับ fsck และไม่ใช่การตรวจสอบไดรฟ์ทั่วไป
BlackJack

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