په دوره توګه، د مرکزي توزیع مرکز ته د تګ لپاره، زه په مختلفو لویو شرکتونو کې مرکه کوم، په ځانګړې توګه په سینټ پیټرزبورګ او مسکو کې، د DevOps موقف لپاره. ما ولیدل چې ډیری شرکتونه (ډیری ښه شرکتونه، د بیلګې په توګه Yandex) دوه ورته پوښتنې کوي:
- انوډ څه شی دی؛
- د کومو دلیلونو لپاره تاسو کولی شئ د ډیسک لیکلو تېروتنه ترلاسه کړئ (یا د مثال په توګه: ولې تاسو ممکن د ډیسک ځای پای ته ورسیږئ ، جوهر ورته دی).
لکه څنګه چې ډیری وختونه پیښیږي، زه ډاډه وم چې زه پدې موضوع ښه پوهیږم، مګر کله چې ما تشریح پیل کړ، د پوهې تشې څرګندې شوې. د دې لپاره چې زما پوهه منظمه کړي، تشې ډکې کړي او نور ځان نه شرموي، زه دا مقاله لیکم، شاید دا به بل چا ته ګټور وي.
زه به له ښکته څخه پیل وکړم، د بیلګې په توګه د هارډ ډرایو څخه (موږ به فلش ډرایو ، 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 inodes نشي پای ته رسیدلی، ځکه چې که اړتیا وي نوي په متحرک ډول رامینځته کیږي.
سرچینه: www.habr.com