ראיון שני עם אדוארד שישקין, מפתח ה- Reiser4 FS

הראיון השני עם אדוארד שישקין, מפתח מערכת הקבצים Reiser4, פורסם.

כדי להתחיל, אנא הזכר לקוראים היכן ועל מי אתה עובד.

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

האם אתה מתחייב כרגע לענף הקרנל הראשי?

לעתים רחוקות מאוד, ורק אם המעסיק שלי דורש זאת. הפעם האחרונה הייתה לפני כשלוש שנים, שלחתי תיקונים כדי להגדיל את תפוקת האחסון המשותף במארחים באמצעות פרוטוקול 9p (שם אחר לעסק הזה הוא VirtFS). יש לציין כאן הערה אחת חשובה: למרות שעבדתי עם לינוקס כבר הרבה זמן, מעולם לא הייתי מעריץ של זה, כלומר, אני "נושם בצורה שווה", כמו בכל דבר אחר. בפרט, אם אני מבחין בפגם, אני יכול להצביע עליו לכל היותר פעם אחת. וכדי שתוכלו אחר כך לעקוב אחר מישהו ולשכנע אותו - זה לא יקרה.

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

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

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

איך אתה מעריך את ההתקדמות בפיתוח Btrfs? האם ה-FS הזה נפטר ממחלות ילדות? איך אתה מציב את זה לעצמך - כ-FS "לבית" או גם לשימוש תאגידי?

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

זה נראה כך (נבדק עבור ליבת לינוקס 5.12). סקריפט מופעל על מערכת מותקנת לאחרונה, אשר בלולאה יוצרת קבצים עם שמות מסוימים בספריית הבית, כותבת להם נתונים בהיסטים מסוימים, ואז מוחקת את הקבצים הללו. אחרי דקה של הפעלת התסריט הזה, שום דבר חריג לא קורה. לאחר חמש דקות, חלק השטח התפוס במחיצה גדל מעט. לאחר שעתיים-שלוש הוא מגיע ל-50% (עם ערך התחלתי של 15%). ואחרי חמש או שש שעות של עבודה, התסריט קורס עם השגיאה "אין מקום פנוי במחיצה." אחרי זה, אתה כבר לא יכול לכתוב אפילו קובץ 4K למחיצה שלך.

מתרחש מצב מעניין: בסופו של דבר לא כתבת שום דבר למחיצה, וכל השטח הפנוי (כ-85%) נעלם איפשהו. ניתוח של קטע הנתון למתקפה כזו יגלה צמתים רבים של עצים המכילים פריט אחד בלבד (אובייקט המצויד במפתח), בגודל של מספר בתים. כלומר, התוכן שתפס בעבר 15% משטח הדיסק התברר כ"מרוח" באופן שווה על כל המחיצה כך שאין איפה לכתוב קובץ חדש, כי המפתח שלו גדול יותר מכל הקיימים, והחינמי בלוקים במחיצה אזלו.

יתרה מכך, כל זה קורה כבר בתצורת ה-Btrfs הבסיסית (ללא כל תצלומי מצב, נפחי משנה וכו'), וזה לא משנה איך תחליטו לאחסן גופי קבצים ב-FS הזה (כ"פרגמנטים" בעץ, או בהיקף של בלוקים לא מעוצבים) - התוצאה הסופית תהיה זהה.

לא תוכל להכפיף מערכות קבצים אחרות במעלה הזרם למתקפה כזו (לא משנה מה יגידו לך). הסברתי את הגורם לבעיה מזמן: מדובר בסטייה מוחלטת של המושג B-tree ב-Btrfs, שמאפשר לו להתנוון באופן ספונטני או מכוון. במיוחד, תחת עומסים מסוימים, מערכת הקבצים שלך "תתפרק" ללא הרף במהלך הפעולה בעצמה, ללא עזרה מבחוץ. ברור שכל מיני תהליכי רקע "לוחצים" יצילו את היום רק במחשבים שולחניים בודדים.

בשרתים קולקטיביים, תוקף תמיד יוכל "להקדים" אותם. מנהל המערכת אפילו לא יוכל לקבוע מי בדיוק הציק לו. הדרך המהירה ביותר לתקן בעיה זו ב-Btrfs היא לשחזר את המבנה של עץ B רגיל, כלומר. עיצוב מחדש של פורמט הדיסק ושכתוב חלקים משמעותיים מקוד ה-Btrfs. זה ייקח 8-10 שנים, כולל איתור באגים, בתנאי שהמפתחים עקבו בקפדנות אחר המאמרים המקוריים על האלגוריתמים ומבני הנתונים הרלוונטיים, ולא שיחקו במשחק "הטלפון השבור", כפי שמקובל (ומעודד) ב-"Linux". דֶרֶך".

כאן אנחנו גם צריכים להוסיף את הזמן הנדרש למפתחים להבין את כל זה. כאן זה נהיה יותר קשה. בכל מקרה, 10 שנים לא הספיקו להם כדי להבין. ובכן, עד אז אתה לא יכול לקוות לנס. זה לא יקרה בצורה של אפשרות הרכבה "שאת ואתה לא ידענו עליה", או בצורה של תיקון שהוא "סתם עניין של עסקים" להכנה. עבור כל "תיקון" נמהר כזה אציג תרחיש חדש של ניוון. עצי B הם אחד הנושאים האהובים עלי, ואני חייב לומר שהמבנים הללו אינם סובלים חירויות עם עצמם!

כיצד אוכל למקם את Btrfs לעצמי? כמשהו שממש לא יכול להיקרא מערכת קבצים, שלא לדבר על שימוש. מכיוון שבהגדרה, ה-FS היא תת-מערכת של מערכת ההפעלה האחראית לניהול יעיל של משאב "שטח הדיסק", שאיננו רואים במקרה של Btrfs. ובכן, תארו לעצמכם שהגעתם לחנות לקנות שעון כדי לא לאחר לעבודה, ובמקום שעון מכרו לכם גריל חשמלי עם טיימר ל-30 דקות לכל היותר. אז המצב עם Btrfs גרוע עוד יותר.

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

ברצוני לבקש תגובה על הפסקת תמיכת Btrfs ב-RHEL.

אין כאן שום דבר מיוחד להגיב, הכל מאוד ברור. היה להם גם כ"תצוגה מקדימה של טכנולוגיה". אז, לא עברתי את ה"תצוגה המקדימה" הזו. אל תתנו לתווית הזו להיתקע לנצח! אבל הם לא יכולים להשיק מוצר בעיצוב פגום עם תמיכה מלאה. RHEL הוא מיזם, כלומר, יחסי סחורות-כסף שנקבעו. Red Hat לא יכול להציק למשתמשים כמו שהם עושים ברשימת התפוצה של Btrfs. רק תארו לעצמכם את המצב: לקוח ששילם את כספו שהרוויח קשה עבור הדיסק וגם לכם עבור תמיכה, רוצה להבין לאן נעלם שטח הדיסק שלו אחרי שהוא לא רשם כלום. מה תענה לו על זה?

נוסף. בין לקוחותיה של רד האט נמנים בנקים ובורסות גדולות ידועות. תארו לעצמכם מה היה קורה אם הם היו נתונים להתקפות DoS על סמך הפגיעות המוזכרת ב-Btrfs. מי לדעתך אחראי לזה? למי שעומד להפנות את האצבע אל קו רישיון ה-GPL, שבו כתוב שהכותב אינו אחראי לכלום, אגיד מיד: "הסתיר את זה!" רד האט יענה, ובצורה כזו שזה לא ייראה מספיק! אבל אני יודע ש-Red Hat לא מתמודד עם סוג כזה של בעיה, לאור הצוות החזק במיוחד של מהנדסי QA שאיתם הייתה לי ההזדמנות לעבוד בצמוד בזמני.

מדוע חברות מסוימות ממשיכות לתמוך ב-Btrfs במוצרים הארגוניים שלהן?

שימו לב כי הקידומת "מיזם" בשם המוצר אינה אומרת הרבה. מיזם הוא מדד לאחריות המוטמע במערכת היחסים החוזית עם הלקוח. אני מכיר רק מפעל אחד המבוסס על GNU/Linux - RHEL. כל השאר, מנקודת המבט שלי, מוצג רק כמפעל, אבל הוא לא אחד. ולבסוף, אם יש ביקוש למשהו, אז תמיד יהיה היצע (במקרה שלנו זו ה"תמיכה" המוזכרת). יש ביקוש לכל דבר, כולל. ותוכנה לא שמישה. איך נוצרת דרישה כזו ומי מתדלק אותה זה נושא אחר.

אז, לא הייתי קופץ למסקנות אחרי שפייסבוק פרסמה את ה-Btrfs על השרתים שלה. יתר על כן, הייתי ממליץ לשמור בקפידה את הכתובות של אותם שרתים בסוד מהסיבות שלעיל.

מדוע הושקע כל כך הרבה מאמץ בניקוי קוד ה-XFS לאחרונה? אחרי הכל, בתחילה מדובר במערכת קבצים של צד שלישי, ו-ext4 היה יציב במשך זמן רב ויש לו המשכיות מגרסאות קודמות יציבות לא פחות. איזה עניין יש ל-Red Hat ב-XFS? האם זה הגיוני לפתח באופן פעיל שתי מערכות קבצים דומות במטרה - ext4 ו-XFS?

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

בשבילי זה כאילו החליפו מרצע בסבון. אין טעם לפתח את ext4 ו-XFS. גם במקביל וגם כל אחד מהם לבחירה. שום דבר טוב לא ייצא מזה. אמנם, בטבע יש הרבה פעמים מצבים שבהם יש הרבה פוטנציאל לצמיחה, אבל אין מקום לגדול. במקרה זה, מתעוררים גידולים חדשים ומכוערים בצורה מוזרה, שכולם מפנים אליהם את האצבע ("אוי, תראה, מה לא תראה בחיים האלה!").

האם לדעתך הנושא של הפרת שכבות הוסדר (במובן שלילי) עם הופעת פונקציות ההצפנה ב-ext4, F2FS (שלא לדבר על RAID ב-Btrfs)?

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

לדוגמה, שיקוף, שהייתה באופן מסורתי פעילות עבור שכבת הבלוק, הגיוני ליישום ברמת מערכת הקבצים. מסיבות אחרות. לדוגמה, שחיתות נתונים "שקטים" (רקב סיביות) מתרחשת בכונני דיסקים. זה כאשר המכשיר פועל כראוי, אך נתוני החסימה נפגעים באופן בלתי צפוי בהשפעת קוונט גמא קשיח הנפלט על ידי קוואזר מרוחק וכו'. הדבר הגרוע ביותר הוא אם הבלוק הזה יתברר כבלוק מערכת FS (סופר בלוק, בלוק מפת סיביות, צומת עץ אחסון וכו'), כי זה בהחלט יוביל לבהלת ליבה.

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

למראות "כלכליות" כאלה יש זכות קיום, וניתן לארגן אותן ביעילות רק ברמת מערכת הקבצים. אחרת, הפרת שכבות היא העמסה של תת-מערכת עם קוד משוכפל למען כמה יתרונות מיקרוסקופיים. דוגמה בולטת לכך היא יישום RAID-5 באמצעות FS. פתרונות כאלה (RAID/LVM משלו במערכת הקבצים) הורגים את האחרון במונחים ארכיטקטוניים. יש לציין גם כאן שהפרת שכבות "מופעלת" על ידי סוגים שונים של רמאים שיווקיים. בהיעדר רעיונות כלשהם, פונקציונליות שיושמה זה מכבר ברמות שכנות מתווספת למערכות המשנה, זו מוצגת כתכונה שימושית מאוד חדשה ונדחפת באופן אקטיבי.

רייזר4 הואשמה בהפרת הרמות "מלמטה". בהתבסס על העובדה שמערכת הקבצים אינה מונוליטית, כמו כל האחרות, אלא מודולרית, הונחה הנחה לא מבוססת שהיא עושה את מה שהרמה שלמעלה (VFS) צריכה לעשות.

האם אפשר לדבר על המוות של ReiserFS v3.6 ו- JFS למשל? לאחרונה הם כמעט ולא קיבלו תשומת לב בליבה. האם הם מיושנים?

כאן עלינו להגדיר מה משמעות המוות של מוצר תוכנה. מצד אחד, הם משמשים בהצלחה (בכל זאת בשביל זה הם נוצרו), מה שאומר שהם חיים. מצד שני, אני לא יכול לדבר בשם JFS (אני לא יודע הרבה), אבל את ReiserFS (v3) קשה מאוד להסתגל לטרנדים חדשים (נבדק בפועל). זה אומר שבעתיד המפתחים ישימו לב לא לזה, אלא לאלה שקל יותר להתאים. מהצד הזה מסתבר שאבוי, הוא מת במונחים אדריכליים. לא הייתי מתמרן כלל את המושג "מיושן מבחינה מוסרית". זה חל היטב, למשל, על ארון בגדים, אבל לא על מוצרי תוכנה. יש מושג של נחיתות ועליונות במשהו. אני בהחלט יכול לומר ש-ReserFS v3 נחות כעת מ-Reiser4 בכל דבר, אבל בסוגים מסוימים של עומס עבודה הוא עדיף על כל שאר ה-FSs במעלה הזרם.

האם אתה יודע על הפיתוח של FS Tux3 ו- HAMMER/HAMMER2 (FS for DragonFly BSD)?

כן אנחנו יודעים. ב-Tux3 התעניינתי פעם בטכנולוגיה של התמונות שלהם (מה שנקרא "מצביעי גרסה"), אבל ב- Reiser4 סביר להניח שנלך למסלול אחר. כבר הרבה זמן אני חושב על תמיכה בצילומי מצב ועדיין לא החלטתי איך ליישם אותם עבור כרכים פשוטים של Reiser4. העובדה היא שטכניקת הנגד ה"עצלנית" החדשה שהציע אוהד רוד עובדת רק עבור עצי B. אין לנו אותם. עבור אותם מבני נתונים המשמשים ב-Reiesr4, מונים "עצלים" אינם מוגדרים - כדי להציג אותם, יש צורך לפתור בעיות אלגוריתמיות מסוימות, שאיש לא לקח על עצמו עדיין.

לפי HAMMER: קראתי מאמר מהיוצר. לא מעוניין. שוב, עצי B. מבנה הנתונים הזה מיושן ללא תקנה. נטשנו אותו במאה הקודמת.

כיצד אתה מעריך את הביקוש הגובר ל-FSs של אשכולות רשת כמו CephFS/GlusterFS/וכו'? האם דרישה זו פירושה שינוי בסדר העדיפויות של מפתחים לכיוון רשת FS וחוסר תשומת לב מספקת ל-FS מקומי?

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

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

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

גישה סבירה מאוד שעדיין לא יושמה בשום מקום. באופן כללי, השאלה באיזה מרחב יש ליישם מערכת קבצים ברשת היא "חרב פיפיות". ובכן, בואו נסתכל על דוגמה. הלקוח הקליט נתונים במחשב מרוחק. הם נפלו למטמון הדפים שלה בצורה של דפים מלוכלכים. זוהי העבודה עבור מערכת קבצים ברשת "שער דק" בחלל ליבה. אז מערכת ההפעלה תבקש ממך במוקדם או במאוחר לכתוב את הדפים האלה לדיסק כדי לשחרר אותם. אז מודול העברת ה-IO (שליחת) רשת FS נכנס לפעולה. זה קובע לאיזה מכונת שרת (צומת שרת) דפים אלה יעברו.

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

אם יש מתגים רבים כאלה, תפוקת האחסון (ביצועי I/O) תקטן. אם האחסון האחורי שלך מורכב מדיסקים איטיים, לא תבחין בירידה משמעותית. אבל אם יש לך דיסקים מהירים (SSD, NVRAM וכו'), אז החלפת הקשר כבר הופכת ל"צוואר בקבוק", ובאמצעות חיסכון בהחלפת הקשר, ניתן להגדיל את הביצועים באופן משמעותי. הדרך הסטנדרטית לחסוך כסף היא להעביר מודולים למרחב הקרנל. לדוגמה, מצאנו שהעברת שרת ה-9p מ-QEMU לקרנל במחשב המארח מובילה לעלייה פי שלושה בביצועי VirtFS.

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

אילו מושגים FSs מקומיים יכולים לשאול מרשתות ולהיפך?

כיום, ל-FSs ברשת, ככלל, יש תוספים על פני FSs מקומיים, אז אני לא כל כך מבין איך אתה יכול לשאול משהו מהאחרון. ובכן, אכן, בואו ניקח בחשבון חברה של 4 עובדים, בה כל אחד עושה את שלו: אחד מחלק, אחר שולח, השלישי מקבל, הרביעי חנויות. והשאלה, מה החברה יכולה ללוות מהעובד שלה שמאחסן אותה, נשמעת איכשהו לא נכונה (כבר היה לה מה שהיא יכלה ללוות ממנו כבר הרבה זמן).

אבל ל-FSs מקומיים יש הרבה מה ללמוד מרשתות. ראשית, כדאי ללמוד מהם כיצד לצבור נפחים לוגיים ברמה גבוהה. עכשיו מה שנקרא מערכות קבצים מקומיות "מתקדמות" צוברות נפחים לוגיים אך ורק תוך שימוש בטכנולוגיית "התקן וירטואלי" שהושאלה מ-LVM (אותה הפרת שכבות זיהומית שהוטמעה לראשונה ב-ZFS). במילים אחרות, תרגום של כתובות וירטואליות (מספרי בלוקים) לאמיתיות ובחזרה מתרחש ברמה נמוכה (כלומר, לאחר שמערכת הקבצים הוציאה בקשת קלט/פלט).

שימו לב שהוספה והסרה של מכשירים לנפחים לוגיים (לא מראות) המסודרים בשכבת הבלוק מובילה לבעיות שספקי "תכונות" כאלה שותקים לגביהן בצניעות. אני מדבר על פיצול במכשירים אמיתיים, שיכול להגיע לערכים מפלצתיים, בעוד שבמכשיר וירטואלי הכל בסדר. עם זאת, מעט אנשים מתעניינים במכשירים וירטואליים: כולם מתעניינים במה שקורה במכשירים האמיתיים שלך. אבל FS דמוי ZFS (כמו גם כל FS בשילוב עם LVM) פועלים רק עם התקני דיסק וירטואלי (הקצו כתובות דיסק וירטואלי מבין כתובות חינמיות, איחו את המכשירים הווירטואליים האלה וכו'). ואין להם מושג מה קורה במכשירים אמיתיים!

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

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

בנוסף, השילוב של תת-מערכות FS+LVM עצמאיות אינו מאפשר לקחת בחשבון את האופי השונה של הכוננים שמהם מצטברים נפחים לוגיים. אכן, נניח שהרכבת נפח לוגי מ-HDD ומכשירי מצב מוצק. אבל אז הראשון ידרוש איחוי, והאחרון לא. עבור האחרונים, אתה צריך להוציא בקשות ביטול, אבל עבור הראשונים, לא וכו'. עם זאת, בשילוב זה די קשה להפגין סלקטיביות כזו.

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

בעיה נוספת מחכה למה שנקרא. מערכות קבצים "Write-Anywhere" (זה כולל גם Reiser4, אם ציינת את מודל העסקאות המתאים במהלך ההרכבה). מערכות קבצים כאלה חייבות לספק כלי איחוי חסרי תקדים בכוחם. ומנהל הווליום ברמה נמוכה לא עוזר כאן, אלא רק מפריע. העובדה היא שעם מנהל כזה, ה-FS שלך יאחסן מפה של בלוקים חינמיים של מכשיר אחד בלבד - וירטואלי. בהתאם, אתה יכול לאחות רק מכשיר וירטואלי. משמעות הדבר היא שהמאחה שלך יעבוד במשך זמן רב על מרחב יחיד עצום של כתובות וירטואליות.

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

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

בנוסף, עם מנהלי נפחים ברמה נמוכה לא תוכל לארגן צילומי מצב מלאים. עם מערכות קבצים דמויות LVM ו-ZFS, אתה יכול לצלם רק תמונות מקומיות, אך לא תמונות גלובליות. צילומי מצב מקומיים מאפשרים לך להחזיר מיידית לאחור רק פעולות קבצים רגילות. ואף אחד שם לא יחזיר פעולות עם נפחים לוגיים (הוספה/הסרה של מכשירים). בואו נסתכל על זה עם דוגמה. בנקודת זמן מסוימת, כאשר יש לך נפח לוגי של שני מכשירים A ו-B המכילים 100 קבצים, אתה מצלם תמונת מצב של מערכת S ואז יוצר עוד מאה קבצים.

לאחר מכן, אתה מוסיף את התקן C לנפח שלך, ולבסוף מחזיר את המערכת שלך ל-Snapshot S. שאלה: כמה קבצים והתקנים מכיל הנפח הלוגי שלך לאחר החזרה ל-S? יהיו 100 קבצים, כפי שאולי ניחשתם, אבל יהיו 3 מכשירים - אלו אותם מכשירים A, B ו-C, למרות שבזמן יצירת תמונת המצב היו רק שני מכשירים במערכת (A ו-B ). פעולת הוספה של מכשיר C לא התגלגלה אחורה, ואם כעת תסיר את מכשיר C מהמחשב, זה ישחית את הנתונים שלך, כך שלפני המחיקה תצטרך לבצע תחילה פעולה יקרה כדי להסיר את המכשיר מהנפח הלוגי מחדש, אשר יפזר את כל הנתונים ממכשיר C למכשירים A ו-B. אבל אם ה-FS שלך תומך בצילומי מצב גלובליים, איזון מחדש כזה לא יידרש, ולאחר חזרה מיידית ל-S, תוכל להסיר בבטחה את התקן C מהמחשב.

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

הדבר הבא ש-FSs מקומיים צריכים ללמוד מרשתות הוא לאחסן מטא נתונים במכשירים נפרדים באותו אופן שבו FSs רשת מאחסנים אותם במכונות נפרדות (מה שנקרא שרתי מטא נתונים). יש אפליקציות שעובדות בעיקר עם מטא נתונים, וניתן להאיץ מאוד את האפליקציות הללו על ידי הצבת המטא נתונים על התקני אחסון יקרים בעלי ביצועים גבוהים. עם השילוב FS+LVM, לא תוכל להפגין סלקטיביות כזו: LVM לא יודע מה יש בבלוק שהעברת אליו (נתונים שם או מטא נתונים).

לא תפיק תועלת רבה מהטמעת LVM משלך ברמה נמוכה ב-FS בהשוואה לשילוב FS+LVM, אבל מה שאתה יכול לעשות טוב מאוד הוא לבלבל את ה-FS כך שבהמשך יהיה בלתי אפשרי לעבוד עם הקוד שלו. ZFS ו-Btrfs, שמיהרו עם מכשירים וירטואליים, הם כולם דוגמאות ברורות לאופן שבו הפרת שכבות הורגת את המערכת במונחים ארכיטקטוניים. אז למה אני כל זה? יתר על כן, אין צורך לבנות LVM ברמה נמוכה משלך במערכת הקבצים. במקום זאת, עליך לצבור התקנים לנפחים לוגיים ברמה גבוהה, כפי שחלק ממערכות הקבצים ברשת עושות עם מכונות שונות (צמתי אחסון). נכון, הם עושים זאת בצורה מגעילה בגלל השימוש באלגוריתמים גרועים.

דוגמאות לאלגוריתמים נוראים לחלוטין הם מתרגם DHT במערכת הקבצים GlusterFS ומה שנקרא מפת CRUSH במערכת הקבצים Ceph. אף אחד מהאלגוריתמים שראיתי לא סיפק אותי מבחינת פשטות ומדרגיות טובה. אז הייתי צריך לזכור אלגברה ולהמציא הכל בעצמי. בשנת 2015, תוך כדי ניסוי עם חבילות על פונקציות גיבוב, המצאתי ורשמתי פטנט על משהו שמתאים לי. עכשיו אני יכול לומר שהניסיון ליישם את כל זה הלכה למעשה. אני לא רואה שום בעיה עם מדרגיות בגישה החדשה.

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

כיצד השפיעו שינויים בתת-המערכת של התקני בלוק ליבה (לדוגמה, המראה של blk-mq) על הדרישות למימוש FS?

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

האם הופעתה של סוגי מדיה חדשים (לדוגמה, SMR, או נוכחותם של כונני SSD) פירושה אתגרים חדשים ביסודו של עיצוב מערכת הקבצים?

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

כמה אנשים עובדים כרגע עם קוד Reiser4 מלבדך?

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

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

האם חברה כלשהי הביעה נכונות לתמוך בפיתוח של Reiser4?

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

אילו תכונות חסרות כעת ב- Reiser4?

אין פונקציית "שינוי גודל" עבור אמצעי אחסון פשוטים, בדומה לזו שנמצאת ב- ReiserFS(v3). בנוסף, פעולות קבצים עם דגל DIRECT_IO לא יזיקו. בשלב הבא, ארצה להיות מסוגל להפריד נפח ל"תתי כרכים סמנטיים", שאין להם גודל קבוע, ואשר ניתן להרכבה ככרכים עצמאיים. בעיות אלו טובות למתחילים שרוצים לנסות את כוחם ב"דבר האמיתי".

ולבסוף, הייתי רוצה לקבל נפחים לוגיים ברשת עם יישום וניהול פשוטים (אלגוריתמים מודרניים כבר מאפשרים זאת). אבל מה של Reiser4 בהחלט לעולם לא יהיה זה RAID-Z, סקרבים, מטמוני שטח פנוי, משתני 128 סיביות ועוד שטויות שיווקיות שעלו על רקע מחסור ברעיונות בקרב מפתחי מערכות קבצים מסוימות.

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

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

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

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

עכשיו לשאלה המרכזית - איך הולך עם הקידום של Reiser4 לליבה המרכזית? האם היו פרסומים על הארכיטקטורה של מערכת הקבצים הזו שדיברת עליהם בראיון האחרון? עד כמה השאלה הזו רלוונטית מנקודת המבט שלך?

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

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

מה חדש ב- Reiser4 בשנים האחרונות?

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

סוף סוף הצלחנו ליישם את הרעיון הוותיק שלנו - מודלים שונים של עסקאות. בעבר, רייזר4 הריץ רק דגם אחד מקודד קשה של מקדונלד-רייזר. זה יצר בעיות עיצוביות. בפרט, צילומי מצב לא אפשריים במודל עסקה כזה - הם יפגמו על ידי רכיב אטומי שנקרא "OVERWRITE SET". Reiser4 תומך כיום בשלושה מודלים של עסקאות. באחד מהם (Write-Anywhere), הרכיב האטומי OVERWRITE SET כולל רק דפי מערכת (תמונות של מפות סיביות של דיסק וכו'), שלא ניתן "לצלם" (בעיית התרנגולת והביצה).

כך שניתן כעת לממש את התמונות בצורה הטובה ביותר. במודל טרנזקציוני אחר, כל הדפים ששונו עוברים רק ל-OVERWRITE SET (כלומר, זה בעצם רישום יומן טהור). מודל זה מיועד למי שהתלונן על פיצול מהיר של מחיצות Reiser4. כעת במודל זה המחיצה שלך תתפרק לא מהר יותר מאשר עם ReiserFS (v3). כל שלושת הדגמים הקיימים, עם הסתייגויות מסוימות, מבטיחים את האטומיות של הפעולות, אבל מודלים עם אובדן אטומיות ושמירה רק על שלמות הסעיף יכולים להיות שימושיים. מודלים כאלה יכולים להיות שימושיים עבור כל מיני יישומים (מסדי נתונים וכו'), שכבר קיבלו חלק מהפונקציות הללו. קל מאוד להוסיף את הדגמים האלה ל- Reiser4, אבל לא עשיתי את זה, כי אף אחד לא שאל אותי, ואני אישית לא צריך את זה.

הופיעו סכימי בדיקה של מטא נתונים ולאחרונה השלמתי אותם במראות "חסכוניות" (עדיין חומר לא יציב). אם סכום הבדיקה של בלוק כלשהו נכשל, Reiser4 קורא מיד את הבלוק המתאים מהתקן העתק. שימו לב ש-ZFS ו-Btrfs לא יכולים לעשות זאת: העיצוב לא מאפשר זאת. שם עליך להפעיל תהליך סריקת רקע מיוחד שנקרא "סקרוב" ולחכות עד שיגיע לבלוק הבעייתי. מתכנתים מכנים אירועים כאלה "קביים".

ולבסוף, הופיעו נפחים לוגיים הטרוגניים, המציעים את כל מה ש-ZFS, Btrfs, שכבת בלוק, כמו גם שילובי FS+LVM באופן עקרוני לא יכולים לספק - קנה מידה מקביל, מקצה כתובות דיסק O(1), העברת נתונים שקופה בין נפחי משנה. לאחרון יש גם ממשק משתמש. עכשיו אתה יכול להעביר בקלות את הנתונים החמים ביותר לכונן בעל הביצועים הגבוהים ביותר בנפח שלך.

בנוסף, ניתן לשטוף בדחיפות כל דפים מלוכלכים לכונן כזה, ובכך להאיץ משמעותית יישומים שקוראים לעתים קרובות fsync(2). אני מציין שפונקציונליות שכבת הבלוק, הנקראת bcache, אינה מספקת חופש פעולה כזה כלל. נפחים לוגיים חדשים מבוססים על האלגוריתמים שלי (יש פטנטים מתאימים). התוכנה כבר די יציבה, אפשר בהחלט לנסות אותה, למדוד ביצועים וכו'. אי הנוחות היחידה היא שלעת עתה עליך לעדכן ידנית את תצורת עוצמת הקול ולאחסן אותה במקום כלשהו.

עד כה הצלחתי ליישם את הרעיונות שלי ב-10 אחוז, עם זאת, הצלחתי במה שנראה לי הכי קשה - לחבר נפחים לוגיים עם הליך הבזק שמבצע את כל הפעולות הדחויות ב-reiser4. כל זה עדיין בענף הניסוי "format41".

האם Reiser4 עובר בדיקות xfstest?

לפחות זה עשה לי כשהכנתי את המהדורה האחרונה.

האם ניתן באופן עקרוני להפוך את Reiser4 לרשת (אשכול) FS באמצעות תוספים?

זה אפשרי, ואפילו הכרחי! אם תיצור קובץ רשת המבוסס על מערכת קבצים מקומית שתוכננה כהלכה, התוצאה תהיה מרשימה מאוד! ב-FSs של רשתות מודרניות, אני לא מרוצה מהנוכחות של רמת אחסון עורפית, המיושמת באמצעות כל FS מקומי. קיומה של רמה זו אינו מוצדק לחלוטין. ה-FS של הרשת חייב לקיים אינטראקציה ישירה עם שכבת הבלוק, ולא לבקש מה-FS המקומי ליצור קבצי שירות אחרים!

באופן כללי, חלוקת מערכות קבצים למקומיות ולרשת היא מהרע. היא נבעה מחוסר השלמות של האלגוריתמים שהיו בשימוש לפני שלושים שנה, ובמקומם עדיין לא הוצע דבר. זו גם הסיבה להופעת מסה של רכיבי תוכנה מיותרים (שירותים שונים וכו'). במובן טוב, צריך להיות רק FS אחד בצורה של מודול ליבה ומערכת של כלי עזר למשתמש המותקן בכל מכונה - צומת אשכול. FS זה הוא גם מקומי וגם רשת. ושום דבר יותר!

אם שום דבר לא יסתדר עם Reiser4 בלינוקס, אני רוצה להציע FS עבור FreeBSD (ציטוט מראיון קודם: "...FreeBSD... יש שורשים אקדמיים... וזה אומר שעם סבירות גבוהה אנו ימצא שפה משותפת עם המפתחים") ?

אז, כפי שגילינו זה עתה, הכל כבר הסתדר בצורה מושלמת עם לינוקס: יש יציאת Reiser4 נפרדת שפועלת עבורו בצורה של ענף מאסטר של המאגר שלנו. לא שכחתי את FreeBSD! הַצָעָה! אני מוכן לעבוד בשיתוף פעולה הדוק עם אלה שמכירים היטב את החלק הפנימי של FreeBSD. אגב: מה שאני מאוד אוהב בקהילה שלהם זה שהחלטות שם מתקבלות על ידי מועצה מעודכנת של מומחים בלתי תלויים, שאין לה שום קשר להונאה ממשלתית של איש קבע אחד.

איך אתה מדרג את קהילת משתמשי לינוקס היום? האם זה הפך ליותר "פופ"?

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

האם ניתן לחזות את התפתחות מערכות הקבצים לחמש עד עשר השנים הבאות? מה לדעתך האתגרים העיקריים שעומדים בפני מפתחי FS?

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

כל תיקון רק מחמיר את הבעיות שלו. נו. ותמיד יש סוגים שונים של "אוונגליסטים" שעבורם "הכל עובד". בעצם, מדובר בתלמידי בית ספר וסטודנטים המדלגים על הרצאות. רק תארו לעצמכם: זה עובד לו, אבל הפרופסור לא. איזה פרץ אדרנלין זה! מנקודת המבט שלי, הנזק הגדול ביותר נגרם על ידי "בעלי המלאכה" שמיהרו "להבריג" בהתלהבות את התכונות הנפלאות של Btrfs על כל מיני שכבות כמו systemd, docker וכו'. - זה כבר דומה לגרורות.

בואו ננסה כעת לעשות תחזית לחמש עד עשר שנים. כבר רשמתי בקצרה מה נעשה ב- Reiser4. האתגר העיקרי של מפתחי FS מקומיים ממעלה הזרם יהיה (כן, זה כבר הפך) חוסר היכולת לעשות עבודה ראויה תמורת שכר. בלי שום רעיונות בתחום אחסון הנתונים, הם ימשיכו לנסות לתקן את ה-VFS, XFS וה-ext4 האומללים הללו. המצב עם VFS נראה קומי במיוחד על רקע זה, מזכיר את המודרניזציה התזזית של מסעדה שבה אין שפים, ולא צפויים שפים.

כעת קוד ה-VFS, ללא כל תנאי, נועל מספר דפי זיכרון בו-זמנית ומזמין את ה-FS הבסיסי לפעול עליהם. זה הוצג כדי לשפר את הביצועים של Ext4 בפעולות מחיקה, אך כפי שקל להבין, נעילה במקביל כזו אינה תואמת לחלוטין מודלים מתקדמים של עסקאות. כלומר, לא תוכל פשוט להוסיף תמיכה עבור מערכת קבצים חכמה כלשהי בקרנל. אני לא יודע מה המצב בתחומים אחרים של לינוקס, אבל בכל הנוגע למערכות קבצים, סביר להניח שכל פיתוח כאן לא תואם את המדיניות שננקטה על ידי טורוואלדס בפועל (פרויקטים אקדמיים נבעטים החוצה, ורמאים אשר אין לי מושג איזה B-tree, אין סוף זיכויים של אמון מונפקים). לכן, נקבע מסלול לדעיכה איטית. כמובן, הם ינסו בכל כוחם להעביר את זה כ"פיתוח".

יתרה מכך, ה"אפוטרופוסים" של מערכות הקבצים, שמבינים שאי אפשר להרוויח הרבה מ"אחסון" בלבד, ינסו את כוחם בעסק רווחי יותר. אלו הן, ככלל, מערכות קבצים מבוזרות ווירטואליזציה. אולי הם יעבירו את ה-ZFS האופנתי למקום אחר שבו הוא עדיין לא קיים. אבל זה, כמו כל FS ממעלה הזרם, דומה לעץ ראש השנה: אם אתה יכול לתלות כמה דברים קטנים אחרים על גבי, אז אתה לא יכול להתעמק יותר. אני מודה שאפשר לבנות מערכת ארגונית רצינית המבוססת על ZFS, אבל מכיוון שאנחנו דנים כעת בעתיד, אני יכול רק לציין בצער ש-ZFS חסר סיכוי בהקשר הזה: עם המכשירים הווירטואליים שלהם, החבר'ה ניתקו את החמצן לעצמם ולדורות הבאים להמשך פיתוח. ZFS הוא נחלת העבר. ו-ext4 ו-XFS הם אפילו לא שלשום.

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

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

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

אז, "העתיד של מערכות הקבצים בלינוקס" הוא עוד תוכנה מקודמת מאוד, אך בקושי שמישה. אחרי Btrfs, בסבירות גבוהה, את מקומו של "עתיד" כזה יתפוס Bcachefs, שזה עוד ניסיון לחצות את שכבת הבלוק של לינוקס עם מערכת קבצים (דוגמה רעה היא מדבקת). ומה אופייני: יש אותן בעיות כמו ב-Btrfs. חשדתי בזה הרבה זמן, ואז איכשהו לא יכולתי להתאפק ובדקתי את הקוד - זה נכון!

המחברים של Bcachefs ו-Btrfs, בעת יצירת ה-FS שלהם, השתמשו באופן פעיל במקורות של אנשים אחרים, והבינו עליהם מעט. המצב מזכיר מאוד את משחק הילדים "טלפון שבור". ואני יכול לדמיין בערך איך הקוד הזה ייכלל בקרנל. למעשה, אף אחד לא יראה את "המגרפות" (כולם ידרכו עליהם אחר כך). לאחר התלבטויות רבות לגבי סגנון הקוד, האשמות בהפרות שאינן קיימות וכו', תוצא מסקנה לגבי "נאמנותו" של המחבר, עד כמה הוא "מקיים אינטראקציה" עם מפתחים אחרים, ועד כמה כל זה יכול להצליח. ואז להימכר לתאגידים.

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

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

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

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

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

מקור: OpenNet.ru