משהו על אינודה

מעת לעת, על מנת לעבור למרכז ההפצה המרכזי, אני מתראיין בחברות גדולות שונות, בעיקר בסנט פטרסבורג ומוסקבה, לתפקיד של DevOps. שמתי לב שחברות רבות (הרבה חברות טובות, למשל Yandex) שואלות שתי שאלות דומות:

• מה זה אינודה;
• מאילו סיבות אתה יכול לקבל שגיאת כתיבה בדיסק (או למשל: מדוע עלול להיגמר לך שטח הדיסק, המהות זהה).

כפי שקורה לעתים קרובות, הייתי בטוח שאני מכיר את הנושא הזה היטב, אבל ברגע שהתחלתי להסביר, התגלו פערים בידע. כדי לסדר את הידע שלי, להשלים את החסר ולא להביך את עצמי יותר, אני כותב את המאמר הזה, אולי זה יועיל למישהו אחר.

אני אתחיל מלמטה, כלומר. מכונן קשיח (נשליך כונני הבזק, כונני SSD ודברים מודרניים אחרים; לדוגמה, הבה ניקח בחשבון כל כונן ישן של 20 או 80 גיגה, מכיוון שגודל הבלוק שם הוא 512 בתים).

הכונן הקשיח אינו יודע כיצד לטפל בשטח שלו בייט אחר בייט; הוא מחולק על תנאי לבלוקים. מספור בלוקים מתחיל מ-0. (זה נקרא LBA, פרטים כאן: ru.wikipedia.org/wiki/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 נקבע בעת יצירת מערכת הקבצים. אנו מסתכלים על המספרים הנדרשים בפרמטר "ספירת Inode" של פלט 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 inode מושקע על קובץ אחד או ספרייה, ובסך הכל יש לנו (עבור מערכת קבצים נתונה) 1 - המצב יותר ממציאותי. ניתן לראות זאת בבירור מהפלט של הפקודה 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