เหตุใดจึงไม่มีการแทรกไฟล์ syscalls

เพื่อความเข้าใจของฉันสำหรับการจัดการไฟล์มีเพียง sys_write syscall ใน Linux ซึ่งจะเขียนทับเนื้อหาไฟล์ (หรือขยายถ้าในตอนท้าย)

เหตุใดจึงไม่มี syscalls สำหรับการแทรกหรือลบเนื้อหาในไฟล์ใน Linux?

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

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

files file-copy system-calls

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

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

— mosvy

@mosvy แต่เป็นแนวคิด "สร้างไฟล์ใหม่แล้วเปลี่ยนชื่อ" ที่ใช้เพราะมันดีในตัวเองหรือว่าเพราะระบบไม่มีวิธีที่ดีกว่านี้หรือไม่ โดยเฉพาะอย่างยิ่งในการดำเนินงานไฟล์ข้อความเช่น "แก้ไขบรรทัดนี้ (เปลี่ยนความยาว)" หรือ "แทรกบรรทัดเหล่านี้ที่นี่" เป็นเรื่องปกติดังนั้นเราสามารถสันนิษฐานได้ว่าการดำเนินการของระบบไฟล์สำหรับฟังก์ชั่นที่แน่นอนเหล่านั้นจะถูกใช้ แน่นอนว่าถ้าไม่มีพวกมันจะทำให้การติดตั้ง fs ง่ายขึ้นมาก ...

— 4994

@meuh OpenVMS ยังทำผ่าน RMS (Record Management Services)

— RonJohn

UNIX เริ่มย้ายออกจากการให้ระบบการจัดการบันทึกภายในระบบไฟล์

— user207421

@ilkkachu เป็นสิ่งที่ดีในตัวเองอย่างไม่ต้องสงสัยเลย ;-) ยิ่งไปกว่านั้นหาก inodes ไม่เปลี่ยนรูปนั่นจะทำให้การใช้การแบ่งปันบล็อกการกำหนดเวอร์ชันและเกือบทุกอย่างมีประสิทธิภาพมากขึ้น (และง่ายกว่ามากสำหรับเหตุผล) ลองคิดดูสิว่าภาษาสคริปต์ทั้งหมดเปลี่ยนเป็นสตริงที่ไม่เปลี่ยนรูปแบบได้อย่างไร แต่ฉันจะตัดมันให้สั้นลงที่นี่ มันยากที่จะพูดคุยถึงข้อมือเกี่ยวกับระบบไฟล์และไม่ฟังดูเหมือนนักต้มตุ๋น ;-) #

— 38911

คำตอบ:

บนระบบลีนุกซ์ล่าสุดที่เป็นไปได้จริง แต่ด้วยบล็อก (4096 ส่วนใหญ่) ไม่ใช่ไบต์ที่มีขนาดเล็กและในระบบไฟล์บางระบบเท่านั้น (ext4 และ xfs)

ข้อความจากfallocate(2)manpage:

int fallocate(int fd, int mode, off_t offset, off_t len);

[ ... ]

การยุบพื้นที่ไฟล์

การระบุการFALLOC_FL_COLLAPSE_RANGEตั้งค่าสถานะ (มีตั้งแต่ Linux 3.15) ในการmodeลบช่วงไบต์จากไฟล์โดยไม่ต้องออกจากหลุม ช่วงไบต์ที่จะยุบเริ่มต้นที่offsetและดำเนินต่อไปสำหรับ len ไบต์ เมื่อเสร็จสิ้นการดำเนินการเนื้อหาของไฟล์ที่เริ่มต้นที่ตำแหน่งoffset+lenจะถูกผนวกเข้ากับตำแหน่ง offsetและไฟล์จะมีlenขนาดเล็กลง

[ ... ]

การเพิ่มพื้นที่ไฟล์

การระบุการFALLOC_FL_INSERT_RANGEตั้งค่าสถานะ (มีให้ตั้งแต่ Linux 4.1) ในการmodeเพิ่มพื้นที่ไฟล์โดยการแทรกรูภายในขนาดไฟล์โดยไม่ต้องเขียนทับข้อมูลใด ๆ ที่มีอยู่ หลุมจะเริ่มต้น offsetและดำเนินการต่อไปเป็นlenไบต์ เมื่อแทรกรูในไฟล์เนื้อหาของไฟล์ที่เริ่มต้นที่offsetจะถูกเลื่อนขึ้น (กล่าวคือเป็นออฟเซ็ตไฟล์ที่สูงขึ้น) เป็นlenไบต์ การแทรกรูในไฟล์จะเพิ่มขนาดไฟล์เป็นlenไบต์

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

"แต่ใช้กับบล็อก (4096) ไม่ใช่หน่วยย่อยเป็นไบต์" - บล็อก 4KiB นั้นพบได้ทั่วไปใน ext4 แต่ไม่รับประกัน Ext4 รองรับขนาดบล็อก 1KiB, 2KiB และ 4KiB ; และฉันจำได้จาก ext2 วันที่โปรเซสเซอร์ Alpha, 8KiB ได้รับการสนับสนุนเช่นกัน คุณไม่สามารถคิดว่าบล็อกเป็น 4KiB ฉันกลัว

— marcelm

4k (ซึ่งเป็นค่าเริ่มต้น) คือผลคูณของ 1k และ 2k ดังนั้นจึงไม่มีปัญหาในการสมมติว่า 4k กับ ext4 ในขณะที่ xfs จะตั้งค่าเป็น 4k ด้วยเช่นกันควรสนับสนุน bs ที่ใหญ่กว่า 4k - สูงสุด 64k แต่ฉันสามารถสร้าง fs ได้เท่านั้น - การติดตั้งล้มเหลวโดยไม่มี ENOSYS และอย่างไรก็ตามคุณไม่สามารถคาดเดาอะไรได้เลย - ฟีเจอร์นี้ไม่รองรับ fs ทั้งหมดดังนั้นจึงเป็นการดีกว่าที่จะพูดว่า block = 4096 ดังนั้นผู้อ่านจึงมีความรู้สึกถึงสัดส่วนมากกว่าปล่อยให้ลอยและปล่อยให้คนอื่นเป็นอะไรก็ได้ หรือแย่กว่านั้นคือ 512 ไบต์หรือเกี่ยวข้องกับขนาดหน้า vm

— mosvy

หลังจากที่คุณแก้ไข (ที่คุณบอกว่าปกติ 4KiB) ฉันเห็นด้วยอย่างเต็มที่! ปัญหาของฉันคือที่ก่อนหน้านี้มันอ่านง่าย ๆ ว่า"บล็อกอยู่เสมอ 4KiB"ซึ่งอาจทำให้ผู้คนตั้งสมมติฐานและเขียนโค้ดบั๊กกี้

— marcelm

เนื่องจากระบบไฟล์ปัจจุบันทั้งหมดไม่ต้องการให้ไฟล์เก็บไว้ในบล็อกหน่วยความจำแบบต่อเนื่อง

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

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

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