การดำเนินการข้อมูลเมตาของระบบไฟล์ใดบ้างที่ถูกเจอร์นัลใน ext4 & xfs

ฉันไม่สามารถหาคำตอบที่เรียบง่ายและตรงไปตรงมาเกี่ยวกับการดำเนินการข้อมูลเมตาของระบบไฟล์ที่ยังคงมีอยู่ในวารสารระบบไฟล์ของ ext4 & xfs โปรดทราบว่าฉันไม่ได้สอบถามเกี่ยวกับสิ่งที่ POSIX ประกาศว่าเป็น "atomic" ฉันกังวลมากขึ้นเกี่ยวกับชุดย่อยของการดำเนินการของระบบไฟล์อะตอมมิกที่มีความทนทานอย่างมีประสิทธิภาพโดยอาศัยการรันด้วยเจอร์นัลที่เปิดใช้งานโดยไม่ต้องงอไปข้างหลังและfsync(2)ตลอดเวลา

การดำเนินการฉันค่อนข้างแน่นอน:

• creat(2)
• link(2)
• unlink(2)
• rename(2)
• mkdir(2)
• rmdir(2)

การดำเนินการฉันไม่แน่ใจทั้งหมดเกี่ยวกับ:

• symlink(2)

symlink(2)กรณีเป็นส่วนใหญ่หนักใจเนื่องจากมีไม่ดูเหมือนจะเป็นวิธีการใด ๆ ที่จะตรงไปตรงมา fsync(2)หรือfdatasync(2)datablocks พื้นฐานที่จัดเก็บเนื้อหาของ symlink ที่ รู้ว่าวารสารดูแลเรื่องนี้สำหรับฉันจะบรรเทา

สำหรับเหตุผลด้านประสิทธิภาพ ext4 โดยค่าเริ่มต้นจะเขียนข้อมูลเมตาของระบบไฟล์ผ่านเจอร์นัลเท่านั้น

ฉันเชื่อว่า XFS ยังทำรายการบันทึกข้อมูลเมตาทั้งหมดเว้นแต่ว่าคุณได้ปรับแต่งระบบไฟล์

ฉันกังวลมากขึ้นเกี่ยวกับการดำเนินการของระบบไฟล์อะตอมมิกที่ทนทานได้อย่างมีประสิทธิภาพโดยอาศัยการรันด้วยเจอร์นัลที่เปิดใช้งานโดยไม่ต้องงอไปข้างหลังและ fsync (2) ตลอดเวลา

ไม่มี. หากคุณต้องการให้แน่ใจว่าการเปลี่ยนแปลงยังคงมีอยู่หลังจากเกิดความผิดพลาดคุณจะต้อง fsync ระยะเวลา การจดบันทึกจะรับประกันได้ว่าในกรณีที่เกิดความผิดพลาดการดำเนินการที่คุณระบุไว้จะไม่ถูกดำเนินการครึ่งหนึ่ง

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

xfstests ดูเหมือนจะอ้างว่า fsync () ในไดเรกทอรีควรคง symlink ใด ๆ ที่มีอยู่

ฉันยังไม่ได้ตรวจสอบสิ่งนี้ เป็นไปได้ที่ฉันจะพลาดบางสิ่งบางอย่าง

xfstests ถูกใช้โดยผู้พัฒนาระบบไฟล์ Linux จำนวนมาก การทดสอบนี้อยู่ในไดเรกทอรี "ทั่วไป" มันบอกเป็นนัยว่าควรใช้กับระบบไฟล์ Linux ทั้งหมด (หรืออย่างน้อยระบบไฟล์อุปกรณ์บล็อกทั้งหมดการทดสอบทำงานโดยใช้อุปกรณ์บล็อกเสมือนพิเศษ)

https://github.com/kdave/xfstests/blob/master/tests/generic/348

# Test creating a symlink, fsync its parent directory, power fail and mount
# again the filesystem. After these steps the symlink should exist and its
# content must match what we specified when we created it (must not be empty
# or point to something else).