เมื่อ fsck เป็นอันตรายหรือไม่?

37

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

เมื่อรีบูตข้อผิดพลาดนี้จะปรากฏขึ้น:

UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)

หลังจากรัน fsck ตามที่แนะนำและยอมรับการแก้ไขด้วยตนเองYข้อผิดพลาดได้รับการแก้ไขและตอนนี้ระบบก็ใช้ได้

ตอนนี้ฉันคิดว่ามันน่าสนใจถ้า fsck ได้รับการกำหนดค่าให้ทำงานและซ่อมแซมทุกอย่างโดยอัตโนมัติเนื่องจากทางเลือกเดียวในบางกรณี (เช่นนี้) กำลังดำเนินการกับดาต้าเซ็นเตอร์ระยะไกลด้วยตนเองและต่อคอนโซลกับเครื่องที่ได้รับผลกระทบ

คำถามของฉันคือ: ทำไม fsck โดยค่าเริ่มต้นขอแทรกแซงด้วยตนเอง? อย่างไรและเมื่อใดที่การแก้ไขโดยโปรแกรมดังกล่าวจะไม่ปลอดภัย? มีกรณีใดบ้างที่ sysadmin อาจต้องการออกจากการแก้ไขที่แนะนำไว้ในบางครั้ง (เพื่อดำเนินการอื่น ๆ ) หรือยกเลิกทั้งหมด

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

15

หากนักพัฒนามั่นใจ 100% ข้อผิดพลาดสามารถแก้ไขได้โดยอัตโนมัติมันจะไม่เกิดข้อผิดพลาดตั้งแต่แรก

— 253751

42

fsckแน่นอนทำให้เกิดอันตรายมากกว่าดีถ้าฮาร์ดแวร์พื้นฐานเสียหายอย่างใด; CPU ไม่ดี, RAM ไม่ดี, ฮาร์ดไดรฟ์ที่กำลังจะตาย, ตัวควบคุมดิสก์หายไปไม่ดี ... ในกรณีเหล่านั้นความเสียหายที่มากขึ้นย่อมหลีกเลี่ยงไม่ได้

หากมีข้อสงสัยมันเป็นความคิดที่ดีที่จะถ่ายภาพดิสก์ที่เสียหายด้วยdd_rescueหรือเครื่องมืออื่น ๆ จากนั้นดูว่าคุณสามารถแก้ไขภาพนั้นได้สำเร็จหรือไม่ ด้วยวิธีนี้คุณยังคงมีการตั้งค่าดั้งเดิมอยู่

— Janne Pikkarainen
แหล่งที่มา

4

ฉันทำงานหนักมากกับฮาร์ดแวร์ที่ล้มเหลวและฉันเห็นด้วยกับสิ่งนี้ สิ่งสุดท้ายที่ฉันต้องทำคือ fsck หากมีผู้ต้องสงสัยว่าฮาร์ดแวร์ไม่ดีทุกประเภท ฉันเคยเห็นเหตุการณ์พลังงานต่ำและการกู้คืนที่ตามมาซึ่งล่าช้าอย่างมากโดย fsck อัตโนมัติ

— jorfus

เพื่อให้ตัวอย่างที่เป็นรูปธรรม: ฉันได้ทำงานกับเครื่องที่มีตัวควบคุมดิสก์ที่ "สุ่ม" (ประมาณ 1 ครั้งใน 10 ^ 5) จะเปลี่ยนการอ่านหรือเขียนเพื่อบล็อก XXXXXXYY บนอุปกรณ์ใด ๆ เพื่อเขียนบล็อก 000000YY บน อุปกรณ์แรก นั่นคือมันทำลายโครงสร้างข้อมูลที่ผิดและไม่มีโครงสร้างที่ผิดไปยังบูตเซกเตอร์และโครงสร้างระบบไฟล์ที่สำคัญต่าง ๆ ของดิสก์สำหรับบูต การเรียกใช้ fsck ในสถานการณ์เช่นนี้ (การอ่านหลายล้านครั้ง) สามารถกำจัดโอกาสที่เหลืออยู่ในการกู้คืนข้อมูล

— Eric Towers

2

1 ใน 10 ^ 5 เป็นจำนวนมาก ... นั่นคือ 10 ไบต์เคย Mb

— เนลสัน

1

@ เนลสัน: มันคือ ... หน่วยที่มี "การถ่ายโอนบล็อกเดียว" ไม่ใช่ "ไบต์" ดังนั้นบล็อกที่ไม่ดีสิบรายการจะเขียนต่อล้านบล็อก (และบล็อกมีขนาดใหญ่กว่าไบต์)

— Eric Towers

21

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

มันไม่เคยมีความคิดที่ดีที่จะลองสิ่งที่ต้องการโดยอัตโนมัติที่ทุก

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

— สเวน
แหล่งที่มา

7

ที่จริงแล้วสิ่งที่ไม่ใช่ความคิดที่ดีคือการพูดว่า " ไม่เคย " เช่นนั้นเมื่อมันไม่เป็นความจริง กรณีการใช้งานซึ่งเป็นความคิดที่ดี: พาร์ติชั่นหลักของเซิร์ฟเวอร์สามารถสร้างขึ้นใหม่ได้จากศูนย์อย่างรวดเร็วในกรณีที่เกิดปัญหา ข้อมูลที่สำคัญจริง ๆ สามารถเข้าถึงได้ผ่านระบบไฟล์ระยะไกลโดยมีความซ้ำซ้อนที่เหมาะสมสำหรับข้อมูลนั้น ฉันค่อนข้างจะใช้โอกาสfsck -p /และfsck -p /varอื่น ๆ ทำงานได้ดีและทำให้เซิร์ฟเวอร์ทำงานได้โดยไม่ต้องดำเนินการด้วยตนเองและเสี่ยงต่อการเกิดภัยพิบัติครั้งใหญ่ที่ไม่เป็นศูนย์% ต่อพาร์ติชันเหล่านั้นซึ่งฉันสามารถสร้างใหม่ได้ถ้าจำเป็น .

— TOOGAM

1

หากระบบที่สามารถติดตั้งได้อย่างง่ายดายผมก็ทำอย่างนั้น ...

— สเวน

1

ที่จะใช้เวลานาน ตัวเลือกคือ: A) ความเสี่ยงทำโดยอัตโนมัติ B) มีคนบอกfsckให้สั่งอาหารแล้วทุกอย่างใช้ได้ดี ใช้เวลาประมาณ 2 นาทีถ้าเป็นเช่นนั้น การหยุดทำงานจนกว่าจะเกิดสิ่งนี้ C) ให้คนอื่นติดตั้งระบบปฏิบัติการอีกครั้ง ใช้เวลา 30+ นาที คุณกำลังเลือกตัวเลือก C บางทีความแตกต่างที่สำคัญที่เรามีคือฉันได้fsckทำงานเป็นเปอร์เซ็นต์มากกว่าเวลาที่คุณพูดในคำตอบของคุณ ประเด็นหลักของฉันไม่ใช่การออกแบบระบบ (ระบบราคาถูก -O ไม่ได้ใช้รีโมตคอนโซล) แต่การพูดว่า " ไม่เคย " เป็นคำที่แข็งแกร่งเกินกว่าจะแม่นยำ

— TOOGAM

เราแค่เห็นด้วยที่จะไม่เห็นด้วย

— สเวน

0

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

Ext3, Ext4, ZFS, btrfs, xfs และ FS ที่ทันสมัยทั้งหมดนั้นสอดคล้องกัน 100% หลังจากการชนหรือรีเซ็ตระบบ

FS ที่ไม่ใช่วารสารเช่น ext2 หรือ vfat นั้นเป็น NOGO ขนาดใหญ่สำหรับรูทของระบบ

ตอนนี้ถ้าระบบของคุณต้องการ fsck ณ เวลาบูตคุณควรถามตัวคุณเองว่าอะไรคือสาเหตุของสิ่งนี้ตั้งแต่แรก?

คุณควรตรวจสอบบันทึกการทำงานของเคอร์เนลของคุณในภายหลังเพื่อค้นหาว่าเกิดอะไรขึ้น คุณควรย้อนเวลากลับไปในล็อกเพื่อค้นหาตั้งแต่เมื่อข้อผิดพลาดเริ่มต้นขึ้น คุณควรตรวจสอบดิสก์ด้วย smartctl อื่น ๆ ... หากคุณต้องการ fsck บน journalized fs มันเป็นความจริงที่ว่าฮาร์ดแวร์ของคุณล้มเหลวสมมติว่า fs ไม่ได้รับความเสียหายจากผู้ดูแลระบบ (ด้วยเครื่องมือระดับบล็อกเช่น dd) หรือข้อผิดพลาด

ดังนั้นจึงเป็นเรื่องโง่ที่จะใช้ fsck เพื่อ "แก้ไข" ปัญหาโดยไม่ต้องตรวจสอบและแก้ไขสาเหตุที่แท้จริง (โดยการแทนที่ / อัปเกรดฮาร์ดแวร์ / เฟิร์มแวร์ / ซอฟต์แวร์ที่ผิดพลาด)

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

— Francois Scheurer
แหล่งที่มา