وقتي طور تي، سينٽرل ڊسٽري بيوشن سينٽر ڏانهن وڃڻ لاءِ، مان مختلف وڏين ڪمپنين ۾ انٽرويو وٺان ٿو، خاص ڪري سينٽ پيٽرسبرگ ۽ ماسڪو ۾، DevOps پوزيشن لاءِ. مون ڏٺو ته ڪيتريون ئي ڪمپنيون (ڪيتريون سٺيون ڪمپنيون، مثال طور Yandex) ٻه ساڳيا سوال پڇن ٿا:
- inode ڇا آهي؛
- ڪهڙن سببن جي ڪري توهان ڊسڪ لکڻ جي غلطي حاصل ڪري سگهو ٿا (يا مثال طور: ڇو ته توهان ڊسڪ جي جاء ختم ڪري سگهو ٿا، جوهر ساڳيو آهي).
جيئن اڪثر ٿئي ٿو، مون کي پڪ هئي ته مان هن موضوع کي چڱي طرح ڄاڻان ٿو، پر جيئن ئي مون وضاحت ڪرڻ شروع ڪيو، ڄاڻ ۾ خال ظاهر ٿيڻ لڳو. منهنجي ڄاڻ کي منظم ڪرڻ لاء، خالن کي ڀريو ۽ وڌيڪ پاڻ کي شرمسار نه ڪيو، مان هي مضمون لکي رهيو آهيان، ٿي سگهي ٿو اهو ڪنهن ٻئي لاء مفيد ٿيندو.
مان هيٺان کان شروع ڪندس، يعني هارڊ ڊرائيو مان (اسان فليش ڊرائيو، SSDs ۽ ٻيون جديد شيون رد ڪنداسين؛ مثال طور، اچو ته ڪنهن به 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 فائل؟ ھڪڙي فائل ھڪڙي يا وڌيڪ فائل سسٽم بلاڪ تي مشتمل آھي جنھن ۾ ان جي ڊيٽا ذخيرو ٿيل آھي. فائل جو نالو ڄاڻڻ، ان کي ڪيئن ڳولهيو؟ مون کي ڪهڙو بلاڪ پڙهڻ گهرجي؟
اهو آهي جتي انوڊس هٿ ۾ اچن ٿا. ext2fs فائل سسٽم ۾ هڪ "ٽيبل" آهي جنهن ۾ سڀني انوڊس جي معلومات شامل آهي. ext2fs جي صورت ۾ انوڊس جو تعداد مقرر ڪيو ويو آھي جڏھن فائيل سسٽم ٺاھيو. اسان tune2fs آئوٽ پٽ جي "انوڊ ڳڻپ" جي پيٽرول ۾ گهربل انگن کي ڏسو، يعني. اسان وٽ 65536 ٽڪر آهن. انوڊ ۾ اسان کي گهربل معلومات شامل آهي: فائل سسٽم بلاڪ جي هڪ فهرست جيڪا اسان ڳولي رهيا آهيون. ڏنل فائل لاءِ انوڊ نمبر ڪيئن ڳوليو؟
لاڳاپيل نالو ۽ انوڊ نمبر ڊاريڪٽري ۾ موجود آهن، ۽ ext2fs ۾ ڊاريڪٽري هڪ خاص قسم جي فائل آهي، يعني. ان جو پنهنجو انوڊ نمبر پڻ آهي. هن شيطاني دائري کي ٽوڙڻ لاءِ، روٽ ڊاريڪٽري ۾ ”مقرر ٿيل“ انوڊ نمبر ”2“ لڳايو ويو. اچو ته انوڊ نمبر 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 ورهاڱي تي واضح طور تي نظر اچي ٿو، فائل سسٽم ۾ مفت بلاڪ جو تعداد ۽ مفت نوڊس جو تعداد تمام گهڻو مختلف آهي.
ان صورت ۾ جيڪڏهن توهان انڊس ختم ڪري ڇڏيو، مان توهان کي ڪو به منتر نه ٻڌائيندس، ڇاڪاڻ ته ... ڪو به نه آهي (جيڪڏهن مان غلط آهيان، مون کي خبر ڏيو). تنهن ڪري پارٽيشنن لاءِ جنهن ۾ ننڍيون فائلون وڌن ٿيون، توهان کي فائيل سسٽم کي سمجھاڻي سان چونڊڻ گهرجي. مثال طور، btrfs انوڊس ختم نه ٿي سگھي، ڇاڪاڻ ته جيڪڏهن ضروري هجي ته نوان متحرڪ طور تي ٺاهيا ويا آهن.
جو ذريعو: www.habr.com