ระบบไฟล์สามารถเขียนด้วย ext4 ได้นานเท่าใด


14

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

ปัญหาดูเหมือนจะได้รับการแก้ไขในโปรแกรมแก้ไขที่บังคับให้บล็อกการจัดสรรในบางสถานการณ์ดังนั้นบังคับให้ข้อมูลไปยังดิสก์หลังจาก 5 วินาทีโดยค่าเริ่มต้น

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

ดูเหมือนว่าจะมีสถานการณ์ที่แตกต่างจากการผนวกเข้ากับไฟล์: เมื่อผนวกแล้วขนาดของไฟล์จะเปลี่ยนแปลงซึ่งเป็นการเปลี่ยนแปลงข้อมูลเมตา ดังนั้นบันทึกประจำวันจะมีความจำเป็นภายใน 5 วินาทีและเนื่องจาก data = สั่งแล้วข้อมูลจะต้องถูกเขียนก่อนหน้านั้นเนื่องจากความกังวลด้านความปลอดภัย (มิฉะนั้นบางส่วนของไฟล์ที่ถูกลบของผู้ใช้คนอื่น ๆ ไฟล์).

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

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

คำตอบ:


16

คุณสามารถตั้งค่าช่วงเวลาการยอมรับเป็นค่าที่กำหนดเองซึ่งฉันเชื่อว่าอาจสูงถึงจำนวนเต็ม 32 บิตที่ไม่ได้ลงชื่อเป็นวินาที ประมาณ 4 พันล้านวินาทีหรือ 136 ปี สิ่งนี้มีให้ในcommitตัวเลือกการเมาท์ซึ่งคุณสามารถใช้งานได้ดังต่อไปนี้ (นี่เป็นเพียงตัวอย่างเท่านั้นคุณยังสามารถตั้งค่านี้ในfstab):

mount /dev/sda1 -t ext4 -o rw,data=writeback,nobh,commit=12345678

ช่วงเวลาการส่งข้อมูลไม่ได้ขึ้นอยู่กับเงื่อนไขประเภทใด ๆ เช่นข้อมูลจะถูกต่อท้ายหรือเขียนทับข้อมูลที่มีอยู่หรืออะไรก็ตาม commitตัวเลือกติด (ที่เริ่มต้นที่ 5 วินาทีถ้าคุณไม่ได้จัดหาติดตั้งตัวเลือกที่ทั้งหมด) เทียบเท่ากับการทำอะไรเช่นนี้ในเปลือกทุบตี:

#!/bin/bash
while :
do
    echo "Syncing all uncommitted data and journal to disk"
    sync
    sleep 5
done

อย่าสับสนdata=orderedและช่วงเวลาการซิงค์ระบบไฟล์ทั่วโลกนี้ ("ช่วงเวลาการส่งมอบ" อาจเป็นคำที่มีความหมายน้อยกว่าสำหรับพวกเราที่เข้าใจการทำงานของโปรแกรมบรรทัดคำสั่งsyncซึ่งในกรณีนี้อาจใช้ชื่อว่า data=orderedเป็นเรื่องเกี่ยวกับลำดับการอัปเดตข้อมูลและข้อมูลเมตา (โดยที่data=writeback"ปลอดภัยน้อยกว่า / เร็วกว่า" และdata=journal"ปลอดภัยยิ่งขึ้น / ช้าลง") commit=12345678เป็นเรื่องเกี่ยวกับความถี่ที่ตัวขับระบบไฟล์บังคับให้ทำการซิงค์แบบเต็มของข้อมูลสกปรกทั้งหมด / เจอร์นัล / เมตาดาต้า / อะไรก็ตามกับสื่อฟิสิคัล และแน่นอนที่สุดคุณสามารถตั้งค่าเป็น 136 ปีถ้าคุณต้องการและติดตั้งdata=writeback,nobhและโปรแกรมที่ไม่โทรfsync()หรือsync()จะมีหน้าสกปรกนั่งอยู่ใน RAM สำหรับ ...

อัปเดต: ตามบริบทของคุณในการแก้ไขคำถามของฉันฉันจะบอกว่าคุณควรเรียกใช้ระบบไฟล์ด้วยตัวเลือกการเมานท์data=journal,commit=1หรือแม้กระทั่งsyncตัวเลือกการเมานต์จนกว่าคุณจะสามารถแก้ไขเคอร์เนลไดรเวอร์กราฟิกของคุณได้ วิธีนี้จะรักษาความสมบูรณ์ของข้อมูลสูงสุด แต่จะต้องเสียค่าใช้จ่ายในการปฏิบัติงาน โดยเฉพาะอย่างยิ่งคุณจะต้องทำสิ่งนี้หากคุณเขียนข้อมูลลงดิสก์บ่อยครั้งซึ่งคุณไม่สามารถที่จะสูญเสียไปได้และนั่นเป็นสิ่งสำคัญอย่างยิ่งหากคุณไม่ "เชื่อมั่น" แอพที่คุณใช้เพื่อใช้fsync()อย่างเหมาะสม

ที่มา: ที่นี่และประสบการณ์ส่วนตัว


1
ขอขอบคุณส่วน "ข้อมูลสกปรกทั้งหมด" เป็นสิ่งที่ฉันกังวล! ฉันกังวลว่ามีข้อยกเว้นเพิ่มเติมนอกเหนือจากการจัดสรรล่าช้า (ซึ่งอาจทำให้ข้อมูลใหม่ยังคงอยู่ในแคชการเขียนแม้หลังจากช่วงเวลาการยอมรับ)
lxgr

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

1
จริงๆ? ในbugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/45มีการกล่าวถึงโดยเฉพาะว่าเพจที่ไม่ได้ถูกจัดสรรจะไม่ถูกเขียนลงดิสก์ในคอมมิชชัน (แต่แน่นอนใน fsync ()) โปรแกรมแก้ไขจะแก้ไขกรณีทั่วไปบางอย่างที่พฤติกรรมนั้นมีปัญหาโดยบังคับให้มีการจัดสรร อย่างไรก็ตามไม่มีอะไรพูดถึงการเขียนทับข้อมูล
lxgr

1
อาดังนั้นcommit=...และsyncไม่เทียบเท่า? หรือว่าบ่งบอกว่าแม้จะมีหน้าที่syncไม่ได้ปันส่วนเพจก็ตาม ฉันไม่สามารถจินตนาการได้ว่าเป็นกรณีเพราะมันจะละเมิดข้อกำหนด POSIX บางทีคุณอาจใช้สคริปต์ทุบตีที่ฉันให้ไว้เพื่อความปลอดภัยของข้อมูลที่ดีขึ้น: P
allquixotic

1
ฉันค่อนข้างแน่ใจว่าเขาหมายถึงอดีตคนหลังจะทำให้ ext4 บน Linux เป็นระบบไฟล์ที่ค่อนข้างอันตรายที่จะใช้;) สคริปต์ดูเหมือนว่าเป็นวิธีการที่ดี ฉันจะลองดูและอาจประเมินแอปพลิเคชันที่สำคัญที่สุดของฉันด้วย strace - บางทีพวกเขาทั้งหมดใช้ fsync () และฉันกังวลมากเกินไป ...
lxgr

1

ไม่ว่าคำตอบสำหรับคำถามของคุณคืออะไรมันไม่สำคัญ

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


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