inodes, การเปรียบเทียบการใช้พื้นที่สำหรับไฟล์ขนาดเล็กจำนวนมาก (xfs, btrfs, ext4)


9

ฉันมีพาร์ติชัน ext4 (LVM บน VM) ที่มีไฟล์ขนาดเล็กจำนวนมากซึ่งฉันต้องขยายทุก 3-4 เดือน

เกี่ยวกับปริมาณพื้นที่ที่ใช้โดย inodes

หนึ่งในระบบไฟล์ xfs, btrfs หรือ ext4 ใช้พื้นที่น้อยลงหรือไม่

กล่าวอีกนัยหนึ่งการสลับไปใช้ btrfs หรือ xfs จะทำให้พาร์ติชันเต็มไปด้วย inodes ที่ช้ากว่าและด้วย ext4


หากคุณใช้ ext4 และคาดว่าจะจัดเก็บประเภทขนาดเล็กส่วนใหญ่คุณควรสร้างมันขึ้นมาmkfs.ext4 -t newsเพื่อผลลัพธ์ที่ดีที่สุด นอกจากนี้ฉันขอแนะนำให้ทดสอบ - สร้าง (บนอุปกรณ์ LVM หรืออุปกรณ์ลูปแบ็ค) แต่ละไฟล์ filesytems ตามลำดับและเริ่มการคัดลอกไฟล์จริงของคุณไปยังจนกว่ามันจะเต็ม เมื่อเต็มแล้วให้ทำdf -i(หรือfind | wc -l) ค้นหาไฟล์ที่จัดการไฟล์ส่วนใหญ่ของคุณ - วิธีที่คุณจะรู้ได้อย่างแน่นอน
Matija Nalis

1
@MatijaNalis -Tพร้อมตัวพิมพ์ใหญ่ T. ไฟล์กำหนดค่ามีตัวเลือกที่ดูมีประโยชน์อื่น ๆ ด้วย
ilkkachu

@ilkkachu ถูกต้องขอบคุณ มันควรจะเป็นmkfs.ext4 -T news
Matija Nalis

ไฟล์มีขนาดเล็กแค่ไหน?
drudru

คำตอบ:


6

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

Btrfs มีการจัดสรร inode แบบไดนามิกดังนั้นจึงไม่มีการเติมเหมือนที่คุณมีกับตาราง inode สำหรับ ext4 (ขนาดที่ตั้งไว้ในเวลาการสร้างระบบไฟล์ ext4)

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


ขอบคุณสำหรับการตอบกลับอย่างรวดเร็ว! ดูเหมือนว่า XFS เป็นตัวเลือกที่ปลอดภัยที่สุดในตอนนี้ เปอร์เซ็นต์การใช้ inode นี้สามารถเปลี่ยนแปลงได้หรือไม่? และถ้าไม่มีวิธีการทำนายว่าจะต้องใช้เท่าไหร่?
abadys

1
คุณควรจะทำเช่นนั้นกับxfs_growfs -m XX
Anthon

3

ใช่และระวังว่าทุกอย่างขึ้นอยู่กับความต้องการของคุณ:

Btrfs (เรียกว่า Butter FS, Better FS หรือ B-Tree FS)

การพิจารณาว่าbtrfsจะสามารถสำหรับทอดกว่าฮาร์ดไดรฟ์หลายมันเป็น poit ที่ดีมากที่จะสามารถสนับสนุนพื้นที่ไดรฟ์ 16 ครั้งกว่าext4 ขนาดพาร์ติชันสูงสุดของระบบไฟล์ btrfs คือ 16 exbibytes และขนาดไฟล์สูงสุดคือ 16 exbibytes ด้วย

จำนวนไฟล์สูงสุด: 2 ** 64

XFS

XFSเป็นที่มีประสิทธิภาพสูง 64 บิตระบบบันทึกไฟล์ XFS สนับสนุนขนาดระบบไฟล์สูงสุด 8 exbibytes สำหรับระบบไฟล์ 64 บิต ตอนนี้RHEL 7.0ใช้ XFS เป็นระบบไฟล์เริ่มต้นรวมถึงการสนับสนุนการใช้ XFS สำหรับ/bootพาร์ติชัน

จำนวนไฟล์สูงสุด: 2 ** 64

Ext4

ext4เป็นที่รู้จักกันดีเพราะของการนำการปรับปรุงความเร็วมากกว่า ext3 ext4 มีข้อ จำกัด บางอย่าง ขนาดไฟล์สูงสุดคือ 16 tebibytes (ซึ่งมีขนาดประมาณ 17.6 เทราไบต์) ไดรฟ์ข้อมูล / พาร์ติชันที่ใหญ่ที่สุดที่คุณสามารถมีได้กับ ext4 คือ 1 exbibyte เช่นเดียวกับระบบไฟล์ที่ทันสมัยที่สุดมันเป็นระบบไฟล์ที่ทำเจอร์นัลซึ่งหมายความว่ามันจะเก็บบันทึกประจำวันของไฟล์ที่ส่วนใหญ่ตั้งอยู่บนดิสก์และการเปลี่ยนแปลงอื่น ๆ ที่เกิดขึ้นกับดิสก์ ไม่ว่าคุณสมบัติทั้งหมดจะไม่รองรับการบีบอัดแบบโปร่งใสการเข้ารหัสแบบโปร่งใสหรือการขจัดข้อมูลซ้ำซ้อน สแน็ปช็อตได้รับการสนับสนุนทางเทคนิค แต่ฟีเจอร์ดังกล่าวนั้นทดลองได้ดีที่สุด

จำนวนไฟล์สูงสุด: 4 พันล้าน

XFS กับ Btrfs

XFS ไม่มี RAID ใด ๆ ในขณะที่ Btrfs RAID นั้นยังไม่เสถียรอย่างสมบูรณ์และอยู่ในช่วงแรก XFSนั้นโตแล้วมากกว่าBtrfsแต่เราไม่สามารถปฏิเสธได้ว่า Btrfs นั้นมีประสิทธิภาพและ FileSystem ที่เติบโตขึ้น

สำหรับตอนนี้ XFS เป็นตัวเลือกของฉัน - โดยเฉพาะอย่างยิ่งเนื่องจากเป็น FS เริ่มต้นสำหรับ RHEL 7 - ยกเว้นว่าฉันต้องการ Btrfs จริงๆ


1
มีข้อมูลพื้นฐานที่ดีเกี่ยวกับระบบไฟล์โดยทั่วไป แต่ฉันไม่เห็นปัญหาเฉพาะของไฟล์ขนาดเล็กที่กล่าวถึงที่นี่
ilkkachu

@ilkkachu "ไฟล์ขนาดเล็กจำนวนมาก" หมายความว่าอะไร? มันคือทั้งหมดที่เกี่ยวกับ inodes เนื่องจากไฟล์ทั้งหมดถูกสร้างขึ้นผ่าน inodes และ inode เป็นโครงสร้างข้อมูลที่ใช้เพื่อแสดงวัตถุระบบไฟล์ ดังนั้นฉันคิดว่าฉันได้อธิบายความต้องการทั้งหมดของผู้แต่งแล้วและฉันได้พูดถึงจำนวนไฟล์สูงสุดแล้ว
FarazX

2

ฉันคิดว่าปัญหาที่คุณมีไม่ใช่พาร์ติชันที่บรรจุด้วย inodes ต่อ se แต่ใช้จำนวน inodes ในระบบไฟล์ไม่เพียงพอ ext4 ขอสงวน inodes แบบคงที่เมื่อสร้างระบบไฟล์ แต่คุณสามารถกำหนดหมายเลขด้วยตัวเลือกเพื่อmkfs.ext4 :

-i bytes-per-inode
ระบุอัตราส่วนไบต์ / inode mke2fs สร้าง inode สำหรับทุก bytes-per-inode bytes ของพื้นที่บนดิสก์ ยิ่งมีขนาดไบต์ต่อไอโหนดมากเท่าไรก็จะสร้างไอโหนดน้อยลงเท่านั้น

-N number-of-inodes
แทนที่การคำนวณเริ่มต้นของจำนวน inodes ที่ควรสำรองไว้สำหรับระบบไฟล์ (ซึ่งขึ้นอยู่กับจำนวนบล็อกและอัตราส่วนไบต์ต่อโหนด) วิธีนี้ทำให้ผู้ใช้สามารถระบุจำนวนของ inodes ที่ต้องการได้โดยตรง

คู่มือระบุอย่างชัดเจนว่าไม่สามารถเปลี่ยนอัตราส่วนไบต์ต่อ inode หลังจากสร้าง FS ได้ แต่จำนวนทั้งหมดจะถูกปรับอัตราส่วนเพื่อให้ตรงกับอัตราส่วนหากมีการปรับขนาด FS

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

-I inode-size
ระบุขนาดของแต่ละ inode เป็นไบต์ ค่า inode-size จะต้องมีกำลัง 2 ที่ใหญ่กว่าหรือเท่ากับ 128

df -iควรแสดงจำนวนของ inodes ที่จัดสรรและใช้งาน ด้วยตัวเลือกเริ่มต้นพาร์ติชั่น 30 GB หนึ่งตัวที่ฉันดูมีหนึ่งไอโหนดสำหรับทุก ๆ 16 kB แต่ถ้าไฟล์ของคุณมีขนาดเล็กมากคุณสามารถตั้งค่าให้พูดว่า-i 4096จะมี inode หนึ่งอันสำหรับทุกบล็อคข้อมูลในระบบ

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

-b block-size
ระบุขนาดของบล็อกเป็นไบต์ ค่าขนาดบล็อกที่ถูกต้องคือ 1024, 2048 และ 4096 ไบต์ต่อบล็อก หากเว้นไว้ขนาดบล็อกจะถูกกำหนดโดยระบบไฟล์ตามขนาดและการใช้งานที่คาดหวังของระบบไฟล์ (ดูที่ตัวเลือก -T)

mkfs.ext4ยังมี-T <type>ตัวเลือกที่สามารถใช้เป็นแบบย่อสำหรับบางส่วนหรือทั้งหมดเหล่านี้ การตั้งค่าอยู่/etc/mke2fs.confที่ Debian ของฉันซึ่งmkfs.ext4 -T smallเทียบเท่ากับ

mkfs.ext4 -b 1024 -I 128 -i 4096

ซึ่งอาจไม่ใช่ชุดตัวเลือกที่ไม่ดีสำหรับไฟล์ขนาดเล็กจำนวนมาก (และไม่มี xattrs)

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

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