Պարբերաբար, Կենտրոնական բաշխման կենտրոն տեղափոխվելու համար հարցազրույցներ եմ ունենում տարբեր խոշոր ընկերություններից, հիմնականում Սանկտ Պետերբուրգում և Մոսկվայում, DevOps-ի պաշտոնի համար: Ես նկատեցի, որ շատ ընկերություններ (շատ լավ ընկերություններ, օրինակ Yandex) տալիս են երկու նմանատիպ հարց.
- ինչ է inode;
- ինչ պատճառներով կարող եք ստանալ սկավառակի գրելու սխալ (կամ, օրինակ, ինչու կարող եք սպառել սկավառակի տարածքը, էությունը նույնն է):
Ինչպես հաճախ է պատահում, ես վստահ էի, որ լավ գիտեմ այս թեման, բայց հենց որ սկսեցի բացատրել, ակնհայտ դարձան գիտելիքների բացեր։ Իմ գիտելիքները համակարգելու, բացերը լրացնելու և ինքս ինձ այլևս չամաչելու համար գրում եմ այս հոդվածը, գուցե այն օգտակար լինի մեկ ուրիշին։
Ես կսկսեմ ներքևից, այսինքն. կոշտ սկավառակից (մենք կհրաժարվենք ֆլեշ կրիչներից, 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 ֆայլը: Ֆայլը բաղկացած է մեկ կամ մի քանի ֆայլային համակարգի բլոկներից, որոնցում պահվում են նրա տվյալները: Իմանալով ֆայլի անունը, ինչպե՞ս գտնել այն: Ո՞ր բլոկները պետք է կարդամ:
Ահա այստեղ է, որ ինոդները հարմար են: Ext2fs ֆայլային համակարգն ունի «աղյուսակ», որը պարունակում է տեղեկատվություն բոլոր ինոդների համար: ext2fs-ի դեպքում ինոդների քանակը սահմանվում է ֆայլային համակարգը ստեղծելիս։ Մենք նայում ենք անհրաժեշտ թվերին tune2fs ելքի «Inode count» պարամետրում, այսինքն. ունենք 65536 հատ։ Inode-ը պարունակում է մեզ անհրաժեշտ տեղեկատվությունը. ֆայլային համակարգի բլոկների ցանկ մեր փնտրած ֆայլի համար: Ինչպե՞ս գտնել տվյալ ֆայլի ինոդ համարը:
Համապատասխան անունը և inode համարը պարունակվում են գրացուցակում, իսկ 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 inode ծախսվում է 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-ը չի կարող ավարտվել, քանի որ Անհրաժեշտության դեպքում դինամիկ կերպով ստեղծվում են նորերը:
Source: www.habr.com