อะไรคือความแตกต่างระหว่าง“ ขนาด inode” และ“ Bytes per inode”

ข้อมูลด้านล่างนำมาจากหน้าคนฉันต้องการทราบความแตกต่างระหว่าง bytes-per-inode และ Inode-size หรือไม่

-i bytes-per-inode

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

-I inode-size

ระบุขนาดของแต่ละ inode ใน bytes.mke2fs สร้าง inodes 256- ไบต์โดยค่าเริ่มต้น ในเมล็ดหลัง 2.6.10 และบางเมล็ดผู้ขายก่อนหน้านี้เป็นไปได้ที่จะใช้ inodes ที่มีขนาดใหญ่กว่า 128 ไบต์เพื่อจัดเก็บคุณลักษณะเพิ่มเติมสำหรับประสิทธิภาพที่เพิ่มขึ้นค่า inode-size จะต้องมีกำลัง 2 ที่ใหญ่กว่าหรือเท่ากับ 128 ยิ่ง inode ใหญ่ขึ้น - เพิ่มขนาดพื้นที่ที่ตารางไอโหนดจะใช้มากขึ้นซึ่งจะช่วยลดพื้นที่ที่ใช้งานได้ในระบบไฟล์และยังสามารถส่งผลเสียต่อประสิทธิภาพการทำงานแอตทริบิวต์ที่ขยายเพิ่มในที่เก็บไอโหนดขนาดใหญ่จะมองไม่เห็นด้วยเคอร์เนลรุ่นเก่า เป็นไปไม่ได้ที่จะเปลี่ยนค่านี้หลังจากสร้างระบบไฟล์แล้ว

ก่อนอื่นไอโหนดคืออะไร? ในโลก Unix inode เป็นชนิดของไฟล์ ชื่อไฟล์ในไดเรกทอรีเป็นเพียงป้ายกำกับ (ลิงก์!) ไปยัง inode ไอโหนดสามารถอ้างอิงได้ในหลาย ๆ ที่ (ฮาร์ดลิงก์!)

-i bytes-per-inode (aka inode_ratio)

ไม่ทราบด้วยเหตุผลบางพารามิเตอร์นี้เป็นเอกสารที่บางครั้งเป็นไบต์ต่อ inodeและบางครั้งเป็นinode_ratio ตามเอกสารนี้เป็นไบต์ / อัตราส่วน คนส่วนใหญ่จะมีความเข้าใจที่ดีขึ้นเมื่อกล่าวว่าเป็นอย่างใดอย่างหนึ่ง (แก้ตัวภาษาอังกฤษของฉัน):

• 1 inode สำหรับทุก ๆ X ไบต์ของที่เก็บข้อมูล (โดยที่ X คือ bytes-per-inode)
• ขนาดไฟล์เฉลี่ยต่ำสุดที่คุณสามารถใส่ได้

สูตร (นำมาจากmke2fs ซอร์สโค้ด ):

inode_count = (blocks_count * blocksize) / inode_ratio

หรือแม้กระทั่งทำให้ง่ายขึ้น (สมมติว่า "ขนาดพาร์ติชัน" เทียบเท่ากับคร่าวๆblocks_count * blocksizeฉันไม่ได้ตรวจสอบการจัดสรร):

inode_count = (partition_size_in_bytes) / inode_ratio

หมายเหตุ 1: แม้ว่าคุณจะให้จำนวนไอโหนดคงที่ในเวลาการสร้าง FS ( mkfs -N ...) ค่าจะถูกแปลงเป็นอัตราส่วนเพื่อให้คุณสามารถใส่ไอโหนดได้มากขึ้นเมื่อคุณขยายขนาดของระบบไฟล์

หมายเหตุ 2: หากคุณปรับอัตราส่วนนี้ตรวจสอบให้แน่ใจว่าได้จัดสรร inode มากกว่าที่คุณวางแผนที่จะใช้ ... คุณไม่ต้องการฟอร์แมตระบบไฟล์ของคุณอีก

-I ขนาด inode

นี่คือจำนวนไบต์ที่ระบบไฟล์จะจัดสรร / สำรองสำหรับ inode แต่ละระบบไฟล์ที่อาจมี พื้นที่ที่ใช้ในการจัดเก็บคุณลักษณะของ inode (อ่านIntro ถึง Inodes ) ใน Ext3 ขนาดเริ่มต้นคือ 128 ใน Ext4 ขนาดเริ่มต้นคือ 256 (เพื่อจัดเก็บextra_isizeและจัดให้มีพื้นที่สำหรับแอตทริบิวต์แบบขยายอินไลน์) อ่านLinux: ทำไมเปลี่ยนขนาด inode

หมายเหตุ: X ไบต์ของ disjkspace ถูกจัดสรรสำหรับแต่ละ inode ที่จัดสรรไม่ว่าจะว่างหรือใช้โดย X = inode-size

bytes-per-inode กำหนดจำนวนของ inodes ที่สร้างขึ้นสำหรับระบบไฟล์นั้น inode-size กำหนดขนาดของ inode เหล่านั้นแต่ละอัน

คุณต้องการไอโหนดจำนวนมากหากคุณต้องการวางไฟล์ขนาดเล็กจำนวนมาก (& / หรือไดเรกทอรีจำนวนมาก) ไว้ใน filesytem

AFAIK คุณต้องการไอโหนดที่มีขนาดใหญ่กว่าขนาด 256 ไบต์เท่านั้นหากคุณต้องการเก็บแอททริบิวต์เสริมสำหรับไฟล์ของคุณ psusi กล่าวในความคิดเห็นที่ไม่ถูกต้อง

แผนผังระบบไฟล์ที่หยาบมาก:

|_|__inodes__|_______________________DATA_________________________________|

• inode-ratio / bytes-per-inode = จำนวนของ inodes สำหรับพื้นที่DATA
• inode-size = size ของแต่ละ inode ในพื้นที่inodes

ฉันชอบคำตอบของ sjas จริงๆมันให้สาระสำคัญของความแตกต่าง

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

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

การดำเนินการ: การสร้าง / ลบ / เปลี่ยนชื่อไฟล์และโฟลเดอร์โดยระบบปฏิบัติการในการจัดเก็บไฟล์อ่าน / เขียน / ย้ายการเปลี่ยนแปลงสิทธิ์เป็นต้น

ไฟล์ที่มีขนาดเป็น N ไบต์จำเป็นต้องสร้างใน "chunks" (บล็อก) แม้ว่าในทางทฤษฎีแล้วใคร ๆ ก็คิดว่าไฟล์นั้นสามารถจัดการได้ตามลำดับของไบต์เดียว (โดยมีเหตุผลพวกเขาสามารถทำได้) สิ่งที่เราต้องจัดการไฟล์ในพื้นที่นั้นคือดัชนีที่กำหนดซึ่งบอกคุณสมบัติของไฟล์ (ชื่อ ฯลฯ ) และแต่ละไฟล์เริ่มต้นด้วย การจัดเก็บ อย่างไรก็ตามเนื่องจากวิธีการที่ฮาร์ดแวร์ถูกออกแบบด้วย "Busters" และ "blocks" และการพิจารณาประสิทธิภาพเหล่านั้น "chunks" นั้นมีขนาดที่เฉพาะเจาะจงและขนาดบล็อกที่หลากหลายของสื่อ (เช่น 512 ไบต์, 4096 ไบต์) และเป็น จัดการโดยเลเยอร์ inodes ซึ่งจะบอกเลเยอร์ถัดไปเกี่ยวกับตำแหน่งของไฟล์และวิธีที่ชิ้นส่วนพันกันเมื่อต้องพบโหลดเข้าสู่หน่วยความจำเป็นต้น

หากมีกระดาษม้วนขนาดใหญ่จำนวนหนึ่งและต้องออกแบบการจัดเก็บข้อมูลสำหรับเอกสารที่ทำจากหน้ากระดาษ (ของอักขระหรือบิตของข้อมูล) สำหรับการจัดเก็บเอกสารหลายสิ่งที่ต้องการคือดัชนี (เพื่อค้นหาเอกสาร) พื้นที่เก็บข้อมูลสำหรับ หน้า (ด้วยตำแหน่งที่เรียบง่ายของหน้า) ใน Unix collation กลไก (inodes) และการตัดจริงลงในหน้า inode-size เป็นขนาดรายการดัชนี (มากหรือน้อย) bytes-per-inode เป็นขนาดหน้า

ผลของการเปลี่ยนการตั้งค่าทั้งสองที่เป็นปัญหา:

changin inode-size - โดยปกติไม่จำเป็นต้องเปลี่ยนติดกับค่าเริ่มต้น (ตามลิงค์ที่โพสต์ในคำตอบก่อนหน้าสำหรับการสนทนา)

bytes-per-inode - ส่งผลกระทบต่อจำนวนไฟล์สูงสุดที่สามารถสร้างได้ในโวลุ่ม (อาจเป็นไปได้ว่าประสิทธิภาพและ "การสิ้นเปลือง" ของไบต์ที่ไม่ได้ใช้)

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

หวังว่ามันจะสมเหตุสมผล (สำหรับฉัน) และโปรดแสดงความคิดเห็นหากฉันมีการใช้งานส่วนใดส่วนหนึ่งของการออกแบบ ext หรือ mkfs อย่างจริงจัง