وقتاً فوقتاً، سینٹرل ڈسٹری بیوشن سینٹر میں جانے کے لیے، میں مختلف بڑی کمپنیوں میں انٹرویو کرتا ہوں، خاص طور پر سینٹ پیٹرزبرگ اور ماسکو میں، DevOps پوزیشن کے لیے۔ میں نے دیکھا کہ بہت سی کمپنیاں (بہت سی اچھی کمپنیاں، مثال کے طور پر Yandex) دو ایسے ہی سوالات پوچھتی ہیں:
- انوڈ کیا ہے؛
- کن وجوہات کی بناء پر آپ کو ڈسک لکھنے میں غلطی ہو سکتی ہے (یا مثال کے طور پر: آپ کی ڈسک کی جگہ کیوں ختم ہو سکتی ہے، جوہر ایک ہی ہے)۔
جیسا کہ اکثر ہوتا ہے، مجھے یقین تھا کہ میں اس موضوع کو اچھی طرح جانتا ہوں، لیکن جیسے ہی میں نے سمجھانا شروع کیا، علم میں خلاء واضح ہوگیا۔ اپنے علم کو منظم کرنے، خالی جگہوں کو پر کرنے اور مزید شرمندہ نہ ہونے کے لیے میں یہ مضمون لکھ رہا ہوں، شاید یہ کسی اور کے لیے مفید ثابت ہو۔
میں نیچے سے شروع کروں گا، یعنی ہارڈ ڈرائیو سے (ہم فلیش ڈرائیوز، ایس ایس ڈی اور دیگر جدید چیزوں کو ضائع کر دیں گے؛ مثال کے طور پر، آئیے کسی بھی 20 یا 80 گیگ پرانی ڈرائیو پر غور کریں، کیونکہ بلاک کا سائز 512 بائٹس ہے)۔
ہارڈ ڈرائیو نہیں جانتی کہ اس کے اسپیس بائٹ کو بائٹ کے ذریعے کیسے ایڈریس کرنا ہے؛ یہ مشروط طور پر بلاکس میں تقسیم ہے۔ بلاک نمبرنگ 0 سے شروع ہوتی ہے۔ (اسے LBA کہا جاتا ہے، تفصیلات یہاں: )
جیسا کہ اعداد و شمار سے دیکھا جا سکتا ہے، میں نے ایل بی اے بلاکس کو ایچ ڈی ڈی لیول کے طور پر نامزد کیا۔ ویسے، آپ دیکھ سکتے ہیں کہ آپ کی ڈسک کا سائز اس طرح ہے:
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 کے معاملے میں inodes کی تعداد سیٹ کی جاتی ہے۔ ہم 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