מערכות קבצים וירטואליות בלינוקס: מדוע הן נחוצות וכיצד הן פועלות? חלק 2

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

כיצד לנטר VFS באמצעות כלי eBPF ו-bcc

הדרך הקלה ביותר להבין כיצד הליבה פועלת על קבצים sysfs זה לראות את זה בפועל, והדרך הקלה ביותר לצפות ב-ARM64 היא להשתמש ב-eBPF. eBPF (קיצור של Berkeley Packet Filter) מורכב ממכונה וירטואלית הפועלת פנימה הליבה, שמשתמשים מורשים יכולים לבקש (query) משורת הפקודה. מקורות הליבה אומרים לקורא מה הליבה יכולה לעשות; הפעלת כלי ה-eBPF על מערכת טעונה מראה מה בעצם הליבה עושה.

למרבה המזל, התחלת השימוש ב-eBPF היא די קלה בעזרת כלים BCC, הזמינות כחבילות מההפצה הכללית לינוקס ומתועד בפירוט ברנרד גרג. כלים bcc הם סקריפטים של Python עם תוספות קטנות של קוד C, מה שאומר שכל מי שמכיר את שתי השפות יכול לשנות אותם בקלות. IN bcc/tools ישנם 80 סקריפטים של Python, מה שאומר שככל הנראה מפתח או מנהל מערכת יוכלו לבחור משהו מתאים לפתרון הבעיה.
כדי לקבל לפחות מושג שטחי על מה העבודה של VFSs על מערכת פועלת, נסה vfscount או vfsstat. זה יראה, נניח, שעשרות שיחות vfs_open() ו"החברים שלו" קורים ממש כל שנייה.

vfsstat.py הוא סקריפט Python עם הוספת קוד C שפשוט סופר קריאות לפונקציות VFS.

בואו ניתן דוגמה טריוויאלית יותר ונראה מה קורה כאשר אנו מכניסים כונן הבזק מסוג USB למחשב והמערכת מזהה אותו.

באמצעות eBPF אתה יכול לראות מה קורה ב /sysכאשר מוכנס כונן הבזק מסוג USB. דוגמה פשוטה ומורכבת מוצגת כאן.

בדוגמה המוצגת למעלה, bcc כלי trace.py מדפיס הודעה כאשר הפקודה מופעלת sysfs_create_files(). אנחנו רואים ש sysfs_create_files() הושק באמצעות kworker זרם בתגובה לעובדה שכונן הבזק הוכנס, אבל איזה קובץ נוצר? הדוגמה השנייה מראה את העוצמה של eBPF. כאן trace.py מדפיס גרעין לאחור (אפשרות-K) ואת שם הקובץ שנוצר sysfs_create_files(). הכנסת משפט בודד הוא קוד C הכולל מחרוזת פורמט הניתנת לזיהוי בקלות המסופק על ידי סקריפט Python המריץ LLVM מהדר בדיוק בזמן. הוא מרכיב את השורה הזו ומבצע אותה במכונה וירטואלית בתוך הקרנל. חתימת פונקציה מלאה sysfs_create_files () יש לשחזר בפקודה השנייה כדי שמחרוזת הפורמט תוכל להתייחס לאחד מהפרמטרים. שגיאות בפיסת קוד C זו גורמות לשגיאות הניתנות לזיהוי מהמהדר C. לדוגמה, אם הפרמטר -l מושמט, תראה את "כשל בהידור BPF text." מפתחים שמכירים את C ו-Python ימצאו את הכלים bcc קל להרחיב ולשנות.

כאשר כונן ה-USB מוכנס, מעקב הליבה לאחור יראה ש-PID 7711 הוא שרשור kworkerשיצר את הקובץ «events» в sysfs. בהתאם לכך, השיחה מ sysfs_remove_files() יראה כי הסרת הכונן הביאה למחיקת הקובץ events, התואם את הרעיון הכללי של ספירת הפניות. במקביל, צפייה sysfs_create_link () עם eBPF בזמן הכנסת כונן ה-USB יראה שלפחות 48 קישורים סמליים נוצרו.

אז מה הטעם בתיק האירועים? נוֹהָג cscope לחיפוש __device_add_disk(), מראה למה זה גורם disk_add_events (), וגם "media_change"או "eject_request" ניתן להקליט בקובץ אירועים. כאן שכבת בלוק הליבה מודיעה למרחב המשתמש ש"דיסק" הופיע ונפלט. שימו לב עד כמה שיטת המחקר הזו אינפורמטיבית על ידי הכנסת כונן USB, לעומת ניסיון להבין איך הדברים עובדים אך ורק מהמקור.

מערכות קבצי שורש לקריאה בלבד מאפשרות התקנים משובצים

כמובן שאף אחד לא מכבה את השרת או את המחשב שלו על ידי הוצאת התקע מהשקע. אבל למה? הסיבה לכך היא שמערכות קבצים מותקנות על התקני אחסון פיזיים עשויות להיות עם כתיבה בפיגור, וייתכן שמבני הנתונים שמתעדים את מצבם לא יסונכרנו עם הכתיבה לאחסון. כאשר זה קורה, בעלי המערכת צריכים להמתין עד לאתחול הבא כדי להפעיל את כלי השירות. fsck filesystem-recovery ובמקרה הגרוע, איבוד נתונים.

עם זאת, כולנו יודעים שהרבה מכשירי IoT, כמו גם נתבים, תרמוסטטים ומכוניות, מריצים כעת לינוקס. לרבים מהמכשירים הללו יש מעט ממשק משתמש, ואין שום דרך לכבות אותם "בצורה נקייה". תארו לעצמכם שמתניעים מכונית עם סוללה מתה כאשר הכוח ליחידת הבקרה נמצא לינוקס כל הזמן קופץ למעלה ולמטה. איך זה שהמערכת מאתחלת בלי הרבה זמן fsckמתי סוף סוף המנוע מתחיל לפעול? והתשובה פשוטה. התקנים משובצים מסתמכים על מערכת קבצי השורש רק לקריאה (מְקוּצָר ro-rootfs (מערכת בסיס לקריאה בלבד)).

ro-rootfs מציעים יתרונות רבים שפחות ברורים מאותנטיות. יתרון אחד הוא שתוכנות זדוניות לא יכולות לכתוב /usr או /lib, אם שום תהליך לינוקס לא יכול לכתוב שם. אחר הוא שמערכת קבצים ניתנת לשינוי במידה רבה היא קריטית לתמיכה בשטח של התקנים מרוחקים, מכיוון שאנשי התמיכה מסתמכים על מערכות מקומיות שזהות נומינלית למערכות השטח. אולי היתרון החשוב ביותר (אך גם הכי ערמומי) הוא ש-ro-rootfs מאלץ מפתחים להחליט אילו אובייקטי מערכת יהיו בלתי ניתנים לשינוי בשלב התכנון של המערכת. עבודה עם ro-rootfs יכולה להיות מביכה וכואבת, מכיוון שמשתני קונסט נמצאים לרוב בשפות תכנות, אך היתרונות שלהם מצדיקים בקלות את התקורה הנוספת.

יצירה rootfs קריאה בלבד דורשת קצת מאמץ נוסף עבור מפתחים משובצים, וכאן VFS נכנס לתמונה. לינוקס דורשת שהקבצים יהיו בפנים /var היו ניתנים לכתיבה, ובנוסף, יישומים פופולריים רבים המריצים מערכות משובצות ינסו ליצור תצורה dot-files в $HOME. פתרון אחד לקובצי תצורה בספרייה הביתית הוא בדרך כלל ליצור מראש ולבנות אותם rootfs. עבור /var גישה אפשרית אחת היא להרכיב אותו על מחיצה נפרדת לכתיבה, תוך כדי / מותקן לקריאה בלבד. אלטרנטיבה פופולרית נוספת היא להשתמש בתושבות כריכה או כיסוי.

תושבות ניתנות לקישור ולערימה, השימוש בהן על ידי מכולות

ביצוע פקודה man mount היא הדרך הטובה ביותר ללמוד על mounts הניתנים לאגד וניתן לשכבות, המעניקות למפתחים ומנהלי מערכת את היכולת ליצור מערכת קבצים בנתיב אחד ואז לחשוף אותה ליישומים בנתיב אחר. עבור מערכות משובצות, משמעות הדבר היא היכולת לאחסן קבצים /var בכונן הבזק לקריאה בלבד, אך נתיב כיסוי או נתיב הרכבה הניתן לקישור tmpfs в /var בעת הטעינה, זה יאפשר לאפליקציות לכתוב שם הערות (קשקושים). בפעם הבאה שתפעיל את השינויים ל /var יאבד. תושבת שכבת-על יוצרת איחוד ביניהם tmpfs ומערכת הקבצים הבסיסית ומאפשרת לך לבצע שינויים לכאורה בקבצים קיימים ב ro-tootf ואילו תושבת הניתנת לחיבור יכולה להפוך חדשים לריק tmpfs תיקיות הנראות כניתנות לכתיבה ב ro-rootfs דרכים. בזמן overlayfs זה הנכון (proper) סוג מערכת הקבצים, הרכבה הניתנת לחיבור מיושם ב מרחב השמות של VFS.

בהתבסס על התיאור של שכבת העל והתושבת הניתנת לקישור, אף אחד לא מופתע מכך מיכלי לינוקס הם נמצאים בשימוש פעיל. בוא נראה מה קורה כשאנחנו משתמשים systemd-nspawn כדי להפעיל את המיכל באמצעות הכלי mountsnoop מ bcc.

Вызов system-nspawn מפעיל את המיכל תוך כדי ריצה mountsnoop.py.

בוא נראה מה קרה:

הפעלה mountsnoop בזמן שהמיכל "מאתחל" מראה שזמן הריצה של המיכל תלוי מאוד ב-mount המקושר (רק ההתחלה של הפלט הארוך מוצגת).

כאן systemd-nspawn מספק קבצים נבחרים ב procfs и sysfs מארח למכולה כשבילים אליו rootfs. למעט MS_BIND דגל שמגדיר את ההר המחייב, כמה דגלים אחרים ב-mount מגדירים את הקשר בין השינויים במרחבי השמות של המארח ו-container. לדוגמה, mount מקושר יכול לדלג על שינויים /proc и /sys לתוך המכולה, או הסתר אותם בהתאם לשיחה.

מסקנה

הבנת פעולתו הפנימית של לינוקס יכולה להיראות כמשימה בלתי אפשרית, מכיוון שהקרנל עצמו מכיל כמות עצומה של קוד, תוך השארת יישומי מרחב משתמש של לינוקס וממשקי שיחות מערכת בספריות C כגון glibc. אחת הדרכים להתקדם היא לקרוא את קוד המקור של תת-מערכת ליבה אחת, עם דגש על הבנת קריאות מערכת וכותרות מרחב משתמש, כמו גם ממשקי הליבה הפנימיים העיקריים, כגון טבלאות file_operations. פעולות קבצים מספקות את עקרון "הכל קובץ", מה שהופך אותן למהנה במיוחד לניהול. קבצי מקור ליבת C בספרייה ברמה העליונה fs/ מציגים יישום של מערכות קבצים וירטואליות, שהן שכבת עטיפה המספקת תאימות רחבה ופשוטה יחסית בין מערכות קבצים פופולריות והתקני אחסון. קישור והרכבת שכבת-על באמצעות מרחבי שמות של לינוקס הם הקסם של VFS שמאפשר יצירת קונטיינרים לקריאה בלבד ומערכות קבצים שורשיות. בשילוב בדיקה של קוד המקור, כלי הליבה eBPF והממשק שלו bcc
מה שהופך את חקר הליבה לקל מתמיד.

חברים, כתבו, האם מאמר זה היה שימושי עבורכם? אולי יש לך הערות או הערות? ומי שמתעניין בקורס מנהל לינוקס מוזמן יום פתוח, שיתקיים ב-18 באפריל.

חלק ראשון.

מקור: www.habr.com