เพื่อที่จะย้ายไปที่ Central Distribution Center ฉันสัมภาษณ์ตำแหน่ง DevOps ที่บริษัทขนาดใหญ่หลายแห่ง ซึ่งส่วนใหญ่อยู่ในเซนต์ปีเตอร์สเบิร์กและมอสโกวเป็นระยะๆ ฉันสังเกตเห็นว่าหลายบริษัท (บริษัทดีๆ หลายแห่ง เช่น Yandex) ถามคำถามที่คล้ายกันสองข้อ:
- ไอโหนดคืออะไร
- ด้วยเหตุผลใดที่คุณได้รับข้อผิดพลาดในการเขียนดิสก์ (หรือตัวอย่างเช่น: เหตุใดพื้นที่ดิสก์ของคุณอาจหมด สาระสำคัญก็เหมือนกัน)
บ่อยครั้งที่ฉันแน่ใจว่าฉันรู้หัวข้อนี้ดี แต่ทันทีที่ฉันเริ่มอธิบาย ช่องว่างในความรู้ก็ปรากฏชัดเจน เพื่อจัดระบบความรู้ของฉันเติมช่องว่างและไม่ทำให้ตัวเองอับอายอีกต่อไปฉันกำลังเขียนบทความนี้บางทีมันอาจจะเป็นประโยชน์กับคนอื่น
ฉันจะเริ่มจากด้านล่างนั่นคือ จากฮาร์ดไดรฟ์ (เราจะทิ้งแฟลชไดรฟ์, SSD และสิ่งที่ทันสมัยอื่น ๆ ตัวอย่างเช่นลองพิจารณาไดรฟ์เก่า 20 หรือ 80 กิ๊กเนื่องจากขนาดบล็อกคือ 512 ไบต์)
ฮาร์ดไดรฟ์ไม่ทราบวิธีจัดการพื้นที่ไบต์ทีละไบต์โดยแบ่งออกเป็นบล็อกตามเงื่อนไข การกำหนดหมายเลขบล็อกเริ่มต้นจาก 0 (ซึ่งเรียกว่า LBA มีรายละเอียดที่นี่: )
ดังที่เห็นได้จากภาพ ฉันกำหนดให้บล็อก LBA เป็นระดับ HDD อย่างไรก็ตาม คุณสามารถดูว่าดิสก์ของคุณมีขนาดบล็อกเท่าใด:
root@ubuntu:/home/serp# blockdev --getpbsz /dev/sdb
512ระดับด้านบนคือพาร์ติชั่น หนึ่งพาร์ติชั่นสำหรับทั้งดิสก์ (อีกครั้งเพื่อความเรียบง่าย) ส่วนใหญ่มักใช้มาร์กอัปพาร์ติชันสองประเภท: msdos และ gpt ดังนั้น msdos จึงเป็นรูปแบบเก่าที่รองรับดิสก์สูงสุด 2Tb gpt เป็นรูปแบบใหม่ที่สามารถจัดการบล็อกได้สูงสุด 1 เซตตะไบต์จาก 512 ไบต์ ในกรณีของเรา เรามีพาร์ติชันประเภท msdos ดังที่เห็นได้จากรูปภาพ พาร์ติชันจะขึ้นต้นด้วยบล็อกหมายเลข 1 ในขณะที่ MBR จะใช้ศูนย์
ในพาร์ติชันแรกฉันสร้างระบบไฟล์ ext2 ขนาดบล็อกเริ่มต้นคือ 4096 ไบต์ ซึ่งสะท้อนให้เห็นในรูปด้วย คุณสามารถดูขนาดบล็อกระบบไฟล์ได้ดังนี้:
root@ubuntu:/home/serp# tune2fs -l /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: a600bf40-f660-41f6-a3e6-96c303995479
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: ext_attr resize_inode dir_index filetype sparse_super large_file
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 65536
Block count: 261888
Reserved block count: 13094
Free blocks: 257445
Free inodes: 65525
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 63
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Filesystem created: Fri Aug 2 15:02:13 2019
Last mount time: n/a
Last write time: Fri Aug 2 15:02:14 2019
Mount count: 0
Maximum mount count: -1
Last checked: Fri Aug 2 15:02:13 2019
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Default directory hash: half_md4
Directory Hash Seed: c0155456-ad7d-421f-afd1-c898746ccd76พารามิเตอร์ที่เราต้องการคือ "ขนาดบล็อก"
ตอนนี้ส่วนที่น่าสนใจคือจะอ่านไฟล์ /home/serp/testfile ได้อย่างไร? ไฟล์ประกอบด้วยบล็อกระบบไฟล์ตั้งแต่หนึ่งบล็อกขึ้นไปซึ่งข้อมูลจะถูกเก็บไว้ รู้ชื่อไฟล์แล้วจะค้นหาได้อย่างไร? ฉันควรอ่านบล็อกใด
นี่คือจุดที่ inodes มีประโยชน์ ระบบไฟล์ ext2fs มี "ตาราง" ที่มีข้อมูลสำหรับ inodes ทั้งหมด จำนวน inodes ในกรณีของ ext2fs ถูกตั้งค่าเมื่อสร้างระบบไฟล์ เราดูตัวเลขที่ต้องการในพารามิเตอร์ "จำนวนไอโหนด" ของเอาต์พุต tune2fs เช่น เรามี 65536 ชิ้น. inode มีข้อมูลที่เราต้องการ: รายการบล็อกระบบไฟล์สำหรับไฟล์ที่เราต้องการ จะค้นหาหมายเลขไอโหนดของไฟล์ที่กำหนดได้อย่างไร?
ชื่อและหมายเลขไอโหนดที่เกี่ยวข้องมีอยู่ในไดเร็กทอรี และไดเร็กทอรีใน ext2fs เป็นไฟล์ประเภทพิเศษ เช่น มีหมายเลขไอโหนดของตัวเองด้วย เพื่อทำลายวงจรอุบาทว์นี้ จึงมีการกำหนดหมายเลขไอโหนด "คงที่" "2" ให้กับไดเร็กทอรีราก ลองดูเนื้อหาของ inode หมายเลข 2:
root@ubuntu:/# debugfs /dev/sdb1
debugfs 1.42.9 (4-Feb-2014)
debugfs: stat <2>
Inode: 2 Type: directory Mode: 0755 Flags: 0x0
Generation: 0 Version: 0x00000000:00000002
User: 0 Group: 0 Size: 4096
File ACL: 0 Directory ACL: 0
Links: 3 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x5d43cb51:16b61bcc -- Fri Aug 2 16:34:09 2019
atime: 0x5d43c247:b704301c -- Fri Aug 2 15:55:35 2019
mtime: 0x5d43cb51:16b61bcc -- Fri Aug 2 16:34:09 2019
crtime: 0x5d43b5c6:00000000 -- Fri Aug 2 15:02:14 2019
Size of extra inode fields: 28
BLOCKS:
(0):579
TOTAL: 1อย่างที่คุณเห็น ไดเร็กทอรีที่เราต้องการนั้นอยู่ในบล็อกหมายเลข 579 ในนั้น เราจะค้นหาหมายเลขโหนดสำหรับโฟลเดอร์โฮม และต่อไปเรื่อยๆ จนกระทั่งในไดเร็กทอรี serp เราจะเห็นหมายเลขโหนดสำหรับไฟล์ที่ร้องขอ หากจู่ๆมีคนอยากตรวจสอบว่าตัวเลขถูกต้องและมีข้อมูลที่จำเป็นอยู่หรือไม่ก็ไม่ใช่เรื่องยาก พวกเราทำ:
root@ubuntu:/# dd if=/dev/sdb1 of=/home/serp/dd_image bs=4096 count=1 skip=579
1+0 records in
1+0 records out
4096 bytes (4,1 kB) copied, 0,000184088 s, 22,3 MB/s
root@ubuntu:/# hexdump -c /home/serp/dd_imageในเอาต์พุต คุณสามารถอ่านชื่อไฟล์ในไดเร็กทอรีได้
ดังนั้นฉันจึงมาถึงคำถามหลัก: “เหตุใดข้อผิดพลาดในการบันทึกจึงเกิดขึ้นได้”
โดยปกติแล้วสิ่งนี้จะเกิดขึ้นหากไม่มีบล็อกว่างเหลืออยู่ในระบบไฟล์ ในกรณีนี้สามารถทำอะไรได้บ้าง? นอกจาก "ลบสิ่งที่ไม่จำเป็น" อย่างชัดเจนแล้ว คุณควรจำไว้ว่าในระบบไฟล์ ext2,3 และ 4 มีสิ่งที่เรียกว่า "จำนวนบล็อกที่สงวนไว้" หากคุณดูรายการด้านบน เรามีบล็อกดังกล่าว “13094” บล็อกเหล่านี้เป็นบล็อกที่เขียนได้โดยผู้ใช้รูทเท่านั้น แต่ถ้าคุณต้องการแก้ไขปัญหาอย่างรวดเร็ว คุณสามารถทำให้ทุกคนสามารถใช้ได้เป็นวิธีแก้ปัญหาชั่วคราว ซึ่งส่งผลให้มีพื้นที่ว่างบางส่วน:
root@ubuntu:/mnt# tune2fs -m 0 /dev/sdb1
tune2fs 1.42.9 (4-Feb-2014)
Setting reserved blocks percentage to 0% (0 blocks)เหล่านั้น. โดยค่าเริ่มต้น คุณมีพื้นที่ว่างในดิสก์ 5% ที่ไม่สามารถเขียนได้ และเมื่อพิจารณาถึงปริมาณของดิสก์สมัยใหม่ อาจมีหลายร้อยกิกะไบต์
มันจะเป็นอะไรอีกล่ะ? อาจเป็นไปได้ว่ามีบล็อกว่าง แต่ไม่มีโหนดอีกต่อไป ซึ่งมักจะเกิดขึ้นหากคุณมีไฟล์จำนวนมากในระบบไฟล์ของคุณที่เล็กกว่าขนาดบล็อกของระบบไฟล์ เมื่อพิจารณาว่า 1 ไอโหนดถูกใช้ไปกับ 1 ไฟล์หรือไดเร็กทอรีและโดยรวมแล้วเรามี (สำหรับระบบไฟล์ที่กำหนด) 65536 - สถานการณ์นั้นสมจริงมากกว่าความเป็นจริง สิ่งนี้สามารถเห็นได้ชัดเจนจากผลลัพธ์ของคำสั่ง df:
serp@ubuntu:~$ df -hi
Filesystem Inodes IUsed IFree IUse% Mounted on
udev 493K 480 492K 1% /dev
tmpfs 493K 425 493K 1% /run
/dev/xvda1 512K 240K 273K 47% /
none 493K 2 493K 1% /sys/fs/cgroup
none 493K 2 493K 1% /run/lock
none 493K 1 493K 1% /run/shm
none 493K 2 493K 1% /run/user
/dev/xvdc1 320K 4,1K 316K 2% /var
/dev/xvdb1 64K 195 64K 1% /home
/dev/xvdh1 4,0M 3,1M 940K 78% /var/www
serp@ubuntu:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 2,0G 4,0K 2,0G 1% /dev
tmpfs 395M 620K 394M 1% /run
/dev/xvda1 7,8G 2,9G 4,6G 39% /
none 4,0K 0 4,0K 0% /sys/fs/cgroup
none 5,0M 0 5,0M 0% /run/lock
none 2,0G 0 2,0G 0% /run/shm
none 100M 0 100M 0% /run/user
/dev/xvdc1 4,8G 2,6G 2,0G 57% /var
/dev/xvdb1 990M 4,0M 919M 1% /home
/dev/xvdh1 63G 35G 25G 59% /var/wwwตามที่เห็นได้ชัดเจนบนพาร์ติชัน /var/www จำนวนบล็อกที่ว่างในระบบไฟล์และจำนวนโหนดที่ว่างจะแตกต่างกันอย่างมาก
ในกรณีที่คุณหมด inodes ฉันจะไม่บอกคาถาใด ๆ ให้คุณเพราะ... ไม่มีเลย (ถ้าฉันผิดโปรดบอกฉันด้วย) ดังนั้นสำหรับพาร์ติชั่นที่มีไฟล์ขนาดเล็กทวีคูณ คุณควรเลือกระบบไฟล์อย่างชาญฉลาด ตัวอย่างเช่น btrfs inodes ไม่สามารถสิ้นสุดได้ เนื่องจาก สิ่งใหม่จะถูกสร้างขึ้นแบบไดนามิกหากจำเป็น
ที่มา: will.com