แนวคิดของการสร้างไฟล์ที่มีศูนย์ไบต์ใน Linux คืออะไร?

ถ้าฉันทำต่อไปนี้:

touch /tmp/test

จากนั้นดำเนินการ

ls -la /tmp/

ฉันสามารถดูtestไฟล์ที่มี0 ไบต์ในไดเรกทอรี

แต่ระบบปฏิบัติการจัดการกับแนวคิดของ0 Bytesอย่างไร ถ้าฉันใส่มันในแง่คนธรรมดา:

0 ไบต์ไม่มีหน่วยความจำเลยไม่มีสิ่งใดถูกสร้างขึ้น

การสร้างไฟล์ต้องหรือควรอย่างน้อยต้องใช้หน่วยความจำบางอย่างใช่มั้ย?

ไฟล์มีสามสิ่งที่ต่างกัน:

• "inode" ซึ่งเป็นโครงสร้างข้อมูลเมตาที่ติดตามว่าใครเป็นเจ้าของไฟล์สิทธิ์และรายการบล็อกบนดิสก์ที่มีข้อมูลจริง
• รายการไดเรกทอรีอย่างน้อยหนึ่งรายการ (ชื่อไฟล์) ที่ชี้ไปที่ไอโหนดนั้น
• บล็อกข้อมูลจริงด้วยตนเอง

เมื่อคุณสร้างไฟล์ว่างเปล่าคุณจะสร้างเฉพาะไอโหนดและรายการไดเรกทอรีที่ชี้ไปที่ไอโหนดนั้น เหมือนกันสำหรับไฟล์ที่กระจัดกระจาย ( dd if=/dev/null of=sparse_file bs=10M seek=1)

เมื่อคุณสร้างฮาร์ดลิงก์ไปยังไฟล์ที่มีอยู่คุณเพียงแค่สร้างรายการไดเรกทอรีเพิ่มเติมที่ชี้ไปที่ไอโหนดเดียวกัน

ฉันมีสิ่งที่ง่ายขึ้นที่นี่ แต่คุณได้รับความคิด

touchจะสร้างinodeและls -iหรือstatจะแสดงข้อมูลเกี่ยวกับ inode:

$ touch test
$ ls -i test
28971114 test
$ stat test
  File: ‘test’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fc01h/64513d    Inode: 28971114    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/1000)   Gid: ( 1000/1000)
Access: 2017-03-28 17:38:07.221131925 +0200
Modify: 2017-03-28 17:38:07.221131925 +0200
Change: 2017-03-28 17:38:07.221131925 +0200
 Birth: -

ขอให้สังเกตว่าtestใช้ 0 บล็อก ในการจัดเก็บข้อมูลที่แสดง inode ใช้บางไบต์ ไบต์เหล่านั้นถูกเก็บไว้ในตาราง inode ดูหน้า ext2 สำหรับตัวอย่างของโครงสร้าง inode

ls(หรือดีstat(2)เรียกระบบ) บอกขนาดของเนื้อหาของไฟล์ จำนวนระบบไฟล์ที่ต้องการสำหรับการทำบัญชีไม่ได้เป็นส่วนหนึ่งของระบบและในรายละเอียดการใช้งานมันไม่ใช่สิ่งที่โปรแกรมโดยทั่วไปควรใส่ใจหรือรู้ การทำให้รายละเอียดการใช้งานปรากฏให้เห็นจะทำให้ระบบแฟ้มมีประโยชน์น้อยลง

ไฟล์นั้นไม่ได้ครอบครองพื้นที่ใด ๆ แต่ระบบไฟล์จะจัดเก็บชื่อไฟล์ที่ตั้งสิทธิในการเข้าถึงและอื่น ๆ ที่คล้ายคลึงกัน

คำตอบง่ายๆ: เพราะมันถูกกำหนดไว้อย่างนั้น

คำตอบที่ยาวกว่า: มันถูกกำหนดด้วยวิธีนี้เนื่องจากการดำเนินการบางอย่างนั้นง่ายกว่าที่คิด:

• หากไฟล์มี 20 ตัวอักษร "A" และคุณลบ "A" ทั้งหมดแล้วไฟล์จะสั้นลง 20 ไบต์ การดำเนินการเดียวกันกับไฟล์ที่มีเพียง "AAAAAAAAAAAAAAAAAAAA" จะต้องจัดการกับกรณีพิเศษของไฟล์ที่หายไป
• ยิ่งกว่านั้นการลบบรรทัดสุดท้ายของไฟล์ข้อความจะต้องเป็นกรณีพิเศษ
• เครื่องมือแก้ไขข้อความที่สำรองข้อมูลเป็นประจำจะต้องใช้รหัสตัวพิมพ์เล็กพิเศษเพื่อจัดการกับสถานการณ์ที่ผู้ใช้อาจลบบรรทัดสุดท้ายไปที่อาหารกลางวันจากนั้นกลับมาและเพิ่มอีกบรรทัดหนึ่ง ภาวะแทรกซ้อนเพิ่มเติมเกิดขึ้นหากผู้ใช้รายอื่นสร้างไฟล์ด้วยชื่อนั้นในเวลาเฉลี่ย

คุณสามารถทำสิ่งต่าง ๆ ได้มากขึ้น: * ไฟล์บันทึกข้อผิดพลาดมักจะถูกสร้างว่างเปล่าให้เติมหากเกิดข้อผิดพลาด * หากต้องการทราบว่ามีข้อผิดพลาดเกิดขึ้นกี่ครั้งคุณนับจำนวนบรรทัดในล็อกไฟล์ หากล็อกไฟล์ว่างเปล่าจำนวนข้อผิดพลาดจะเป็นศูนย์ซึ่งทำให้รู้สึกสมบูรณ์แบบ * this-is-the-logging-directoryบางครั้งคุณเห็นไฟล์ที่ทุกข้อความที่เกี่ยวข้องที่อยู่ในชื่อไฟล์เช่น สิ่งนี้จะป้องกันผู้ดูแล overeager จากการลบไดเรกทอรีว่างเปล่าหลังจากการติดตั้งและยังป้องกันข้อผิดพลาดที่โปรแกรมหรือผู้ใช้สร้างไฟล์โดยไม่ตั้งใจซึ่งโปรแกรมต้องการเห็นไดเรกทอรีในภายหลัง gitโปรแกรม (และอื่น ๆ ) มีแนวโน้มที่จะไม่สนใจไดเรกทอรีว่างและถ้าโครงการ / ผู้ดูแลระบบ / ผู้ใช้ต้องการที่จะมีการบันทึกว่าไดเรกทอรีที่มีอยู่แม้ว่ามันจะไม่มีเนื้อหาที่เป็นประโยชน์ (ยัง), คุณอาจจะเห็นไฟล์ที่ว่างเปล่าชื่อemptyempty.directoryหรือ

ไม่มีการดำเนินการที่ซับซ้อนมากขึ้น:

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

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

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

การใช้การเปรียบเทียบที่ง่ายที่สุด:

ลองเปรียบเทียบไฟล์กับพูดน้ำหนึ่งแก้ว

'touch / tmp / test' เป็นเหมือนการสร้างแก้วเปล่าโดยไม่มีน้ำอยู่เลย แก้วว่างเปล่าดังนั้นขนาดจึงเป็นศูนย์ แต่แก้วมีอยู่จริง

ในสำนวนระบบไฟล์แก้วคือเมตาดาต้าในขณะที่เนื้อหาของแก้วคือข้อมูล meta-data มีเนื้อหาทุกประเภทตามที่กล่าวไว้ในโพสต์ก่อนหน้า

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

คิดแบบนี้บอกว่าโปรแกรมกำลังติดตามการสืบค้น SQL ที่ส่งไปยังเซิร์ฟเวอร์ของคุณ โปรแกรมต้องการระบุว่าเป็นการบันทึกการร้องขอลงในไฟล์ข้อความธรรมดา แต่ยังไม่มีการร้องขอใด ๆ ที่ถูกบันทึกไว้ สิ่งที่ควรมีลักษณะอย่างไร /var/log/acme-sql-server/queries.logฉันเถียงว่ามันควรจะเป็นไฟล์ศูนย์ขนาดใหญ่ที่ ด้วยวิธีนี้คุณสามารถคิดออกได้เมื่อเริ่มต้นการบันทึก (เวลาสร้างไฟล์) เมื่อมีการอัปเดตครั้งล่าสุด (เช่นเมื่อสร้าง) จำนวนการสืบค้นที่บันทึกไว้ (จำนวนบรรทัดใหม่ในไฟล์ = 0) และใครกำลังทำการบันทึก (เซิร์ฟเวอร์ Acme SQL) สำหรับกรณีเช่นนี้จะมีประโยชน์ที่จะมีแนวคิดของไฟล์ว่างเปล่าที่มีอยู่ ณ ตำแหน่งเฉพาะ