כאשר יוצאת גרסה חדשה של OpenZFS, מנהלים רבים תוהים האם כדאי לעדכן עכשיו או לחכות שהאבק ישקע. OpenZFS 2.4 השאלה מעניינת עוד יותר, כי זה מגיע עם שינויים עמוקים בביצועים, כלי ניהול חדשים, ודיון קהילתי על שימוש במועמדים לשחרור במערכות ייצור.
תכונות כלליות של OpenZFS 2.4
OpenZFS 2.4 מוצג כגרסה של אופי יציב ושאפתני למדי הפרויקט, שתוכנן הן עבור סביבות לינוקס והן עבור סביבות FreeBSD, הדגיש, בזמן מתן התיוג הסופי שלו, כי המטרה היא להמשיך לקדם את בגרות מערכת הקבצים ומנהל האמצעים תוך שמירה על תאימות עם גרעינים עדכניים והבטחת אבטחת נתונים.
גרסה זו מאחדת תכונות רבות שהיו בפיתוח מאז מסגרת 2.3 ותיקוני הביניים שלו: שיפורי ביצועים ב- שכבת הצפנהכלי ניהול חדשים כגון כתיבה מחדש של zfsיכולות מכסות גמישות יותר, ושינויים פנימיים שנועדו להפחית פיצול, לייעל את ביטול הכפילויות ולשפר היבטים מורכבים כגון ניהול בלוקי כנופיות או התנהגות עם דיסקים בעייתיים.
הקהילה גם הקדישה תשומת לב מיוחדת ל- אינטגרציה עם גרעינים מודרנייםבלינוקס, התמיכה מוצהרת מגרסה 4.18 ועד לענפי LTS עדכניים (כולל גרעין 6.18 בזמן הגרסה היציבה של גרסה 2.4), בעוד שב-FreeBSD, גרסאות מגרסה 13.3 ואילך מכוסות, כולל גרסה 14.0 וענפים חדשים יותר בהכנה כמו גרסה 15.0.
תמיכה בפלטפורמה ותאימות ליבה עם OpenZFS 2.4
אחד מעמודי התווך של OpenZFS 2.4 הוא... תאימות רחבה לפלטפורמותעבור מנהלים רבים זהו מפתח, משום שהוא מאפשר להם לשדרג גרסאות של מערכת ההפעלה מבלי לאבד את תכונות ZFS הצפויות.
בצד של לינוקס, OpenZFS 2.4 מציין תאימות עם גרעינים החל מגרסה 4.18 ועד לסדרה ... 6.18 יציבזה מכסה הכל, החל מהפצות ארגוניות שמרניות ועד לסביבות מעודכנות ביותר שנשארות מעודכנות עם הליבה העדכנית ביותר. בין לבין נמצא כל הספקטרום של הגרסאות הנפוצות: גרסאות LTS המשמשות בשרתים, ליבות מותאמות אישית וגרסאות שאומצו על ידי פרויקטים כמו CentOS Stream או דומים.
ב-FreeBSD, הגרסה החדשה תומכת ב- 13.3 מעתה והלאה, כולל גרסה 14.0 ומעלה שכבר נמצאות באופק, כמו גרסה 15.0 הקרובה. טווח רחב זה מבטיח שגם מערכות שכבר נמצאות בתהליכי ייצור וגם פריסות מהדור הבא יוכלו להמשיך להשתמש ב-OpenZFS ללא צורך בתיקונים מוזרים או פתרונות מותאמים אישית.
מאחורי תאימות זו מסתתר מאמץ מתמשך שכבר ניכר בסדרה OpenZFS 2.3.xעדכונים קודמים, כגון 2.3.4, תמיכה מורחבת בליבת השרת עד 6.16 ותיקונים מאוחדים שהחלו להופיע ב-RCs קודמים. OpenZFS 2.4 ממשיך את הנקודה שבה הפסיק והולך צעד קדימה, מתיישר עם ליבות עדכניות ומשפר את החוויה עבור אלו שמעדכנים את מחסנית הבסיס שלהם בתדירות גבוהה יחסית.
מכסות ויכולות ניהול שטחים חדשות
בין התכונות החדשות והמעשיות ביותר עבור מנהל המערכת נמצאות השיפורים במערכת של מכסות שנקבעו מראשOpenZFS 2.4 מציג את היכולת להגדיר מכסות ברירת מחדל עבור משתמשים, קבוצות ופרויקטים, כך שניתן יהיה לשלוט בצריכת שטח בצורה אחידה יותר מבלי שיהיה צורך להגדיר כל מקרה באופן ידני.
פונקציה זו מאפשרת, לדוגמה, הגדרת דמי בסיס לכל המשתמשים שנוצרים במערך נתונים ספציפי, או כדי לקבוע מגבלות פרויקט המוחלות אוטומטית כאשר מוקצים משאבים חדשים. זהו כלי שימושי מאוד בסביבות מרובות משתמשים, אירוח, מעבדות וכל תרחיש שבו רוצים למנוע מחדל מלמלא את כל המאגר.
תמיכה במכסות ברירת מחדל אינה מחליפה מכסות ספציפיות קיימות, אלא משלימה אותן. מנהל המערכת יכול להגדיר פוליטיקה עולמית ולאחר מכן לחדד אותו עם חריגים עבור משתמשים או קבוצות ספציפיות הזקוקות ליותר (או פחות) מקום. כל זה מנוהל באמצעות כלי ZFS סטנדרטיים, תוך שמירה על אותו מודל מאפיינים שכבר מוכר.
קלט/פלט ישיר, קלט/פלט ללא מטמון והתנהגות כתיבה לא מיושרת
מבחינת ביצועים, OpenZFS 2.4 מביא שינוי מעניין מאוד בניהול של קלט/פלט ישירעד כה, שימוש בקלט/פלט ישיר במצבים מסוימים עלול להתנגש עם יישור הכתיבה ולהוביל לנתיבי קוד לא אופטימליים. הגרסה החדשה מציגה מנגנון כך שכאשר לא ניתן ליישם קלט/פלט ישיר באופן אידיאלי, נעשה שימוש במצב חלופי. IO קל משקל ללא מטמון שתוכנן במיוחד עבור סוג זה של תרחיש.
מה המשמעות של זה בפועל? שכתבים שאינם תואמים היטב את ההתאמות הצפויות מפסיקים להיות מקרה פתולוגי ובמקום זאת מטופלים באמצעות מסלול אופטימלי בתוך ZFS. התקורה מצטמצמת, צווארי בקבוק מסוימים נמנעים, ומושגת התנהגות צפויה יותר, במיוחד בסביבות בהן יישומים המשתמשים בקלט/פלט ישיר מתקיימים יחד עם אחרים שאינם עושים זאת.
שינוי זה שימושי במיוחד בעומסי עבודה תובעניים שבהם המטרה היא לסחוט את הביצועים אחסון מבלי להתפשר על ערבויות השלמות שמציע ZFS. עם גיבוי שתוכנן במיוחד, OpenZFS מתאים יותר למציאות של יישומים רבים שלא תמיד דבקים ביישור הפעולות האידיאלי.
ויסות הקצאה מאוחד והפחתת פיצול ב-OpenZFS 2.4
שינוי משמעותי נוסף שמגיע עם OpenZFS 2.4 הוא הצגת אלגוריתם חדש עבור ויסות הקצאה מאוחדמאחורי שם זה מסתתר מנגנון שמטרתו להפחית את הפיצול של התקנים וירטואליים (vdevs) ולשפר את אופן פיזור הכתיבות כאשר המערכת נמצאת תחת לחץ.
עד כה, הקצאת בלוקים במצבי עומס גבוה יכלה בסופו של דבר לייצר דפוסי חלוקה אשר, לאורך זמן, העדיפו את פיצול של vdevהאלגוריתם המאוחד שואף ליצור הרמוניה בין קצב ההקצאה, כך שהמאגר ישמור על מבנה מסודר יותר ועונשים על ביצועים מופחתים כאשר המקום מתחיל להיגמר או כאשר תמהיל גדלי הבלוקים מגוון מאוד.
שינויים מסוג זה פחות מורגשים מפקודה חדשה, אך הם בעלי ערך רב בפריסות ארוכות טווח, בהן מאגר גדל, מאוזן מחדש, מתווספות סביבות פיתוח וירטואליות חדשות (vdevs) ופעולות תחזוקה מבוצעות לאורך שנים. על ידי שיפור בקרת ההקצאה, OpenZFS 2.4 מסייע בתחזוקה. התנהגות יציבה יותר לאורך זמןאפילו כאשר המערכת נמצאת בשימוש אינטנסיבי.
שיפורי הצפנה עם AVX2 ו-AES-GCM
מבחינת אבטחה וביצועים, OpenZFS 2.4 כולל סדרה של אופטימיזציות בשימוש ב- AVX2 עבור AES-GCMבמילים פשוטות יותר: יישום ההצפנה שוכלל כדי לנצל טוב יותר את היכולות של מעבדים מודרניים בעלי הוראות וקטוריות מתקדמות אלה.
התוצאה היא הצפנה מהירה יותר מבלי להתפשר על ערבויות קריפטוגרפיות, דבר הבולט במיוחד במערכות המטפלות בכמויות גדולות של נתונים מוצפנים או בסביבות בהן מבוצעות פעולות רבות בו זמנית על מערכי נתונים מוגנים. להפחית את תקורת המעבד בקשר עם הצפנה, ניתן לטפל ביותר בקשות או להקדיש יותר משאבים למשימות מערכת אחרות.
בפועל, מנהלים יכולים להמשיך להסתמך על הפונקציות של הצפנת ZFS מקורית כדי להגן על נתונים רגישים ללא ההשפעה המשמעותית על הביצועים של הדורות הקודמים. הצפנה לא הופכת ל"חופשית", אך היא הופכת לניתנת יותר לניהול תחת עומסי עבודה שבהם בעבר הייתה צוואר בקבוק ברור.
ZIL בפיתוחי וידאו מיוחדים ושיפורים ב-special_small_blocks
OpenZFS 2.4 מביא גם תכונות חדשות בנוגע ל- פיתוח וידאו מיוחד, אותם התקנים שנועדו לאחסן סוגים מסוימים של נתונים (כגון מטא-דאטה, בלוקים קטנים או טבלאות מניעת כפילויות) על גבי מדיה מהירה יותר, בדרך כלל SSD או NVMe.
מצד אחד, כעת ניתן לאפשר את ZIL (יומן כוונות ZFS) התמקמו על vdevs ייעודיים כאשר זמינים. זה מקל על ריכוז כתיבות סינכרוניות על התקנים בעלי השהייה נמוכה, ומשפר את זמן התגובה של יישומים המסתמכים על פעולות עתירות סנכרון, כגון מסדי נתונים או מערכות העברת הודעות עם נוכחות חזקה.
מצד שני, התנהגות הנכס מתרחבת special_small_blocks כך כתבי ZVOL הם יכולים גם לנחות ב-vdevs מיוחדים, לא רק בבלוקים מסוימים של קבצים רגילים. יתר על כן, המגבלה שהערך חייב להיות חזקה של שתיים הוקלה, כך שהמנהל יכול לבחור גדלים עדינים יותר המותאמים לעומס העבודה בפועל שלו במקום להיות מוגבל לאפשרויות נוקשות.
יחד, שיפורים אלה מאפשרים תכנון של ארכיטקטורות אחסון שבהן ה- הנתונים הקריטיים ביותר (מטא-נתונים, בלוקים קטנים, ZILs, טבלאות מניעת כפילויות וכו') מאוחסנים על גבי מדיה מהירה יותר, בעוד שרוב הנתונים נשארים על גבי דיסקים זולים יותר. כל זה מגיע עם גמישות רבה יותר בהגדרת מה נחשב "קטן" ומה לא.
zfs rewrite ו-zfs rewrite -P: העברת נתונים ביעילות
סדרת 2.3 כבר הביאה איתה את אחת התכונות הבולטות ביותר של התקופה האחרונה: פקודה משנית. כתיבה מחדש של zfsOpenZFS 2.4 לוקח את הכלי הזה צעד קדימה על ידי שילוב הגרסה zfs rewrite -Pמה שמוסיף אפשרויות חדשות בעת העברת נתונים בתוך מאגר.
הפקודה zfs rewrite מאפשר "לשכתב"תוכן הקובץ או מערך הנתונים מועתק מבלי לשנות את משמעותו הלוגית, אלא מועבר פיזית לאזורים אחרים בעלי מאפיינים פנימיים שונים. זה מאפשר שינויים כגון אלגוריתם הדחיסה, סוג סכום הבדיקה, האם מוחל ביטול כפילויות, מספר העותקים או אפילו ההתקן המועדף, מבלי שיהיה צורך להעתיק את הנתונים למרחב המשתמש ולכתוב אותם מחדש."
יש לכך מספר יתרונות ברורים: זה מפחית את תעבורת הקלט/פלט בהשוואה לשיטת "העתקה ושינוי שם" הקלאסית, ממזער את ההשפעה על המטמון, ומונע פרקי זמן ארוכים שבמהלכם נתונים מועברים דרך כלים חיצוניים. יתר על כן, מכיוון שאין שינוי הגיוני בתוכן, השעה לא השתנתה וגם לא מאפיינים אחרים הנראים מנקודת מבטו של המשתמש, מה שאומר שיישומים רבים אפילו לא מודעים לפעולה.
אפשרות zfs rewrite -P מוסיף את האפשרות של שמור על זמן הלידה ההגיוני של הבלוקים ככל האפשר, מה שעוזר למזער את גודל זרימות השכפול המצטברות. על ידי שמירה על יציבות מידע זו, פעולות שליחה/קבלה עוקבות יכולות לזהות טוב יותר מה השתנה בפועל ומה לא, ובכך להפחית את כמות הנתונים שיש להעביר בין מערכות.
יתרון חשוב נוסף הוא שתהליך הכתיבה מחדש מוגן על ידי מנעולי טווח רגיל, כך שהוא יכול לפעול במקביל לעומסי עבודה אמיתיים מבלי לחסום את המערכת יתר על המידה. במערכי נתונים עם sync=always התועלת גדולה אף יותר, משום שבהיעדר שינוי לוגי של נתונים, לא נכפות כתיבות נוספות ב-ZIL, מה שנמנע מעלות נוספת בפעולות סינכרוניות.
אפשרויות ניהול חדשות ב-OpenZFS 2.4: -a|–all, scrub range ו-prefetch של BRT
OpenZFS 2.4 גם משפר ומרחיב את ארסנל כלי הניהול עם מספר אפשרויות שימושיות מאוד לשימוש יומיומי. אחת מהן היא הוספת האפשרות -א|–הכל בפקודות שמבצעות משימות תחזוקה בבריכות, כגון קרצוף, חיתוך או אתחול.
אפשרות זו מאפשרת להפעיל פעולה המשפיעה על כל הבריכות המיובאות הכל בבת אחת, במקום שיהיה צורך לעבור ידנית על כל אחד מהם. זה מפשט מאוד את הדברים בשרתים המנהלים מספר מאגרי מידע, מפחית טעויות אנוש ומקל על אוטומציה קלה יותר.
בנוסף, האפשרות להשיק zpool scrub מוגבל ל טווחי זמן ספציפיים דרך האפשרויות -S -Eפונקציונליות זו מוערכת מאוד כאשר ברצונך לסקור רק חלון זמן בו יש חשד לבעיות, או כאשר ברצונך לפזר את עלות הבדיקה על פני מספר פעולות חלקיות כדי לא להשפיע יתר על המידה על הביצועים הכוללים.
תכונה חדשה ורלוונטית נוספת היא הוספת zpool prefetch -t brt לטעון מראש לזיכרון את טבלת ייחוס בלוקים (טבלת שיבוט בלוקים)זה מאפשר ניצול טוב יותר של פונקציונליות שכפול הבלוקים שהוצגה בגרסאות קודמות, מה שמפחית את ההשהיה בעת גישה למבנים פנימיים המעורבים בתכונה זו.
הרשאות, שינוי שם של כלים ושיפורים בביטול כפילויות ובשיבוט חסימות
בין השיפורים הקטנים אך המשמעותיים שמשפרים את החוויה, OpenZFS 2.4 מוסיף הרשאה חדשה. שלח: מוצפןתוכנה זו, שתוכננה לספק שליטה מפורטת יותר על מי יכול לשלוח נתונים מוצפנים, עובדת היטב עם צוותים שיש להם הפרדת אחריות בין אלו שמנהלים תמונות מצב, אלו שמטפלים בשכפול ואלו שיש להם גישה למפתחות הצפנה.
גם שירותים מסורתיים קיבלו שמות, כגון arc_summary y arcstat, אשר לאחר מכן נודעו zarcsummary y zarcstatשינוי זה מסייע במניעת התנגשויות בשמות ומבהיר שמדובר בכלים המשויכים ל-ZFS, דבר שימושי במערכות עם רכיבים מרובים החושפים פקודות דומות.
באופן פנימי, סדרת 2.4 מצטברת אופטימיזציות ותיקונים חדשים זה חל הן על ביטול כפילויות והן על שכפול בלוקים. מבני נתונים עוברים שיפור, מקרי קצה מתוקנים, ומחפשים דפוסי גישה טובים יותר כדי להפוך את ההשפעה על הזיכרון והמעבד לניתנת לניהול בקלות רבה יותר. שינויים אלה אינם גלויים ישירות למשתמש, אך הם גורמים להתנהגות יציבה יותר ופחות הפתעות תחת עומסי עבודה מורכבים.
בלוקי גנג', ashift, vdevs איטיים של ילדים וטופולוגיות מיוחדות
OpenZFS 2.4 משלב גם מגוון שיפורים ותיקונים לעומת בלוקי כנופיותזוהי תכונה פנימית של המערכת שנועדה לטפל בבלוקים שלא ניתן למקם אותם באופן קונבנציונלי. למרות שרוב המשתמשים אינם מקיימים אינטראקציה ישירה איתם, כל כשל בחלק זה של הקוד עלול להיות בעל השלכות חמורות, כך שהתיקונים והאופטימיזציות הרבות הכלולים הן חדשות טובות לחוסן הכולל של המערכת.
במקביל, הטיפול ב א-הסטההפרמטר שמגדיר את יחידת ההקצאה המינימלית בהתאם לגודל הפיזי של הסקטורים של ההתקן. ניהול משמרות טוב יותר מפחית את האפשרות לכתיבת נתונים רבים יותר מהנדרש לדיסקים עם סקטורים גדולים ומסייע בשמירה על רמות ביצועים מקובלות לאורך כל חיי המאגר.
תכונה חדשה ומעניינת נוספת היא היכולת לגרום ל-vdv לילדים להתנהג בצורה... איטי באופן חריג ניתן לבצע "התאמת הגדרות" זמנית. במקום לפגוע בביצועי המערכת כולה, ניתן להסירם מהמחשב לזמן מה, דבר שימושי מאוד כאשר דיסקים מתחילים להיכשל, כוננים חווים בעיות לסירוגין, או בסביבות עבודה בעלות חומרה לא עקבית.
לבסוף, יש להם אילוצי טופולוגיה רגועים ב-VDEVs מיוחדים וב-deduplication, זה מאפשר גמישות רבה יותר בעת תכנון מאגרי מידע עם תצורות מתקדמות. זה מאפשר שילוב טוב יותר של התקנים מהירים עבור מטא-דאטה, טבלאות עם ביטול כפילויות, ZILs ואלמנטים רגישים אחרים מבלי להיתקל במגבלות נוקשות מדי בהגדרת הפריסה.
OpenZFS 2.3.4: תחזוקה, כתיבה מחדש ראשונית של zfs ואיחוד
כדי להבין לעומק את הקפיצה שמייצגת 2.4, כדאי להעיף מבט חטוף על OpenZFS 2.3.4, גרסת תחזוקה שהופיעה זמן קצר קודם לכן והניחה חלק מהיסודות למה שאוחד מאוחר יותר בענף הראשי החדש.
גרסה 2.3.4 הגיעה חודשיים לאחר 2.3.3 עם דגש חזק מאוד על עמידות ותאימותהיא הרחיבה את התמיכה בליבת לינוקס עד גרסה 6.16, תוך שמירה על המינימום על גרסה 4.18, ואישרה תאימות עם FreeBSD מגרסה 13.3 ואילך, כולל גרסה 15.0 הקרובה. במילים אחרות, היא כבר הכינה את היסודות לקיום משותף עם מערכות בסיס מודרניות מבלי להתפשר על יציבות.
סקירה ספציפית זו ראתה את הופעת הבכורה של הגרסה הראשונית של הפקודה zfs rewriteתוכנן בדיוק עבור העברת נתונים מבלי לשנות את התוכן הלוגי שלהם ובלי לנקוט באסטרטגיות מסורבלות יותר כמו העתקה/שינוי שם או שליחה/קבלה עם שינוי שם של מערך נתונים. המטרה הייתה להציע כלי המסוגל לאזן מחדש מאגר לאחר הוספת vdevs, להפחית פיצול של קבצים שנכתבו באופן אקראי, או להחיל מאפייני אחסון חדשים על נתונים קיימים.
בהשוואה לחלופות מסורתיות, zfs rewrite זה מהיר יותר משום שזה מונע את העברת הנתונים למרחב המשתמש. במערכי נתונים עם sync=alwaysיתר על כן, זה משפר את הביצועים מכיוון שמאחר שהנתונים אינם משתנים באופן לוגי, לא מופעלות כתיבות נוספות ב-ZIL. כל זאת מבלי לגעת בשום דבר. mtime או מטא-נתונים אחרים גלוי ליישומים, מה שממזער את ההשפעה על התוכנה הפועלת מעליו.
גרסה 2.3.4 סיפקה גם מגוון הגדרות ספציפיות ל-FreeBSDזה כלל שיפורי אריזה וסדרה של תיקונים קלים שליטשו כמה פינות בקוד. זו לא הייתה גרסה שנועדה להכניס שינויים משבשים, אלא לכוונן את היציבות לפני קפיצה לענף 2.4 עם חבילה גדולה יותר של תכונות חדשות.
OpenZFS 2.4 RC1, RC2, RC4: בדיקות, משוב ודיון קהילתי
לפני שהוכרזה סדרת 2.4 כסדרה יציבה, הפרויקט פרסם מספר לשחרר מועמדים (RC1, RC2, RC4) במטרה לאפשר למשתמשים מתקדמים ולמפתחים לבדוק אותם ולדווח על בעיות. גרסאות מועמדות אלו כבר כללו כמעט את כל התכונות שדנו בהן: מכסות ברירת מחדל, קלט/פלט ללא מטמון כגיבוי, ויסות הקצאה מאוחד, שיפורי הצפנה, ZIL בפיתוחי vdevs מיוחדים, הרחבות special_small_blocks, הרשאות חדשות, שינוי שם כלים ועוד.
ההערות של RC1 ו-RC2 הדגישו את חשיבות הקהילה יבדוק את הבניינים ולשלוח משוב דרך GitHub, כולל פקודות לרשימה קלה של שינויים ביחס לענף ההפניה (עם שילובים של git cherry (השוואת zfs-2.3-release עם מערכות ה-RC השונות). המסר היה ברור: המטרה הייתה לבדוק את הקוד בסביבות אמיתיות לפני שתתייג אותו כ"יציב".
עם זאת, המראה של RC ספציפי (לדוגמה, 2.4.0-RC4הכללת .NET Framework (RF) בגרסה של FreeBSD המסומנת כ-RELEASE, כמו 15.0, עוררה דאגה. חלק מהמשתמשים תהו מדוע הוחלט לכלול אחת כזו. מועמד לשחרור OpenZFS בגרסה הנחשבת יציבה של מערכת ההפעלה במקום לפנות לענף קודם שכבר קיים. בחירה זו עוררה חוסר שביעות רצון בקרב אלו המעדיפים שמערכת הקבצים עליה נשענים הנתונים שלהם תתבסס אך ורק על גרסאות סופיות.
הספקות נסבו סביב עמידות ההחלטה הזו: אם מישהו מתקין את FreeBSD 15.0 עם OpenZFS 2.4.0-RC4 ואז לא עוקב אחר הענף -CURRENT, יש חשש מ"תקיעה" במשך מספר חודשים עם גרסה מועמדת לשחרור עד שתגיע גרסה מינורית או נקודה חדשה בסדרה. הייתה גם חשש שמהדורות עתידיות כמו 15.1 ישלב RC נוסף (לדוגמה, 2.4.1-RC3 היפותטי) במקום גרסה סופית.
מאחורי הוויכוח הזה ישנן דרכים שונות להבין מה "מועמד לשחרור"בהקשר רגיש כמו מערכת קבצים. עבור אנשים מסוימים, Release Candidate (RC) היא למעשה גרסה יציבה, הדורשת רק שינויים קלים. עבור אחרים, לעומת זאת, זהו קוד שלא אמור לשמש כבסיס למערכת המסומנת כ-RELEASE ויש לשמור אותו לאלו שעוקבים מקרוב אחר ענפי פיתוח."
בכל מקרה, ה-RCs מילאו את משימתם מגרש בדיקהשיפורים אלה אפשרו זיהוי באגים, התאמות לפרטים והגעה בטוחה הרבה יותר לגרסה "2.4 יציבה". אלו שמעדיפים אבטחה מעל הכל עדיין יכולים להישאר על ענפים קודמים כמו 2.3.x עד שיראו את 2.4 בשלה מספיק בייצור.
כל מה ש-OpenZFS 2.4 מביא מבוסס על החוסן שהפרויקט צבר עם סדרת 2.3 ועדכוני התחזוקה שלו, המשלבים שיפורי תאימות ליבה, כלים חדשים כגון כתיבה מחדש של zfsהעדכון כולל התאמות לביטול כפילויות ושיבוט בלוקים, אופטימיזציות להצפנה, שינויים פנימיים בבלוקים של קבוצות (gang blocks) ובשיפט (ashift), ומגוון אפשרויות ניהול חדשות. בעוד שהתעוררה מחלוקת מסוימת בנוגע לשימוש במועמדים לגרסה חדשה (release candidates) במערכות הפעלה מסוימות, גרסה 2.4 היציבה מציעה קפיצת מדרגה משמעותית עבור אלו המעוניינים להפיק יותר מ-ZFS על לינוקס ו-FreeBSD מבלי להתפשר על ערבויות השלמות והחוסן המבוססות.
