ทำไมคุณไม่สามารถ fsck พาร์ติชันที่เมาท์?

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

จาก:

http://linux.die.net/man/8/fsck.ext3

"โปรดทราบว่าโดยทั่วไปก็ไม่ปลอดภัยที่จะทำงานe2fsckบนระบบไฟล์ติดตั้ง. ยกเว้นอย่างเดียวคือถ้า-nตัวเลือกที่มีการระบุและ-c, -lหรือ-Lตัวเลือกที่ไม่ได้ระบุไว้. อย่างไรก็ตามแม้ว่าจะปลอดภัยที่จะทำเช่นนั้นผลที่พิมพ์โดยe2fsckมี ไม่ถูกต้องหากติดตั้งระบบไฟล์หากe2fsckถามว่าควรตรวจสอบระบบไฟล์ที่ติดตั้งหรือไม่คำตอบที่ถูกต้องคือ '' ไม่ '' ผู้เชี่ยวชาญที่รู้ว่ากำลังทำอะไรอยู่ควรพิจารณาตอบคำถามนี้ด้วยวิธีอื่น ทาง "

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

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

WAFL ของ NetApp ยังมีเครื่องมือตรวจสอบออนไลน์ อาจมีคนอื่น ๆ

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

นอกเหนือจากข้อเท็จจริงที่ว่ามันอาจจะฆ่า I / O ทรูพุตของคุณหากระบบไฟล์ถูกแก้ไขในขณะที่มันเป็น fsck แล้วก็ไม่มีทางที่ fsck สามารถติดตามการเปลี่ยนแปลงและรายงานความไม่แน่นอนได้

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

จุดสำคัญของ fsck คือการรายงานความไม่สอดคล้องกันของระบบไฟล์ซึ่งเป็นการละเมิดค่าคงที่

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

คุณทำได้ fsck -n / dev / sda1 จะทำอย่างนั้นอย่างน้อยใน ext3 ฉันเพิ่งทดสอบมัน :)

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

แต่ทำไมคุณถึงต้องลองทดสอบความตายด้วยตัวคุณเอง? เพราะเจ้านายของคุณกำลังจะทำการทดสอบอีกครั้งเมื่อเขารู้ว่าทำไมเซิร์ฟเวอร์อีเมลถึงไม่รู้จักรูทไดรฟ์ตอนนี้