תכנון מערכת זיכרון אל– כשל עבור יישומים משובצים

תכנון מערכת זכרון כתוצאה מהתקדמות מתמדת בתחום זיכרונות ההבזק, הפך אחסון כמויות גדולות של נתונים בשנים האחרונות קל יותר גם במערכות משובצות מחשב קטנות. הנתונים שאותם רבים מבין מפתחי המערכות המשובצות מאחסנים, ועליהם הם פועלים, הפכו להיות בעלי ערך רב. תכנון מערכת שבה הנתונים נשמרים באופן כזה שלעולם אינם אובדים או ניזוקים ותמיד נשמרים במצב עקבי, היא משימה מורכבת שדורשת מחשבה רבה ויצירתיות. חברת HCC–Embedded השקיעה זמן ומאמצים משמעותיים לניתוח, תכנון ובדיקה של פתרונות למערכת קבצים עבור התקנים משובצים.
מערכת סטנדרטית לאחסון מדיה מוצגת באיור 1. חשוב להבין את גישת השכבות הזו כאשר מתכננים מערכת אמינה. דרישות האמינות מגיעות מהשכבה העליונה עד לתחתונה: ליישום נדרשת רמת שירות מתאימה ממערכת הקבצים; למערכת הקבצים נדרשת רמה מתאימה של שירות מהכוננים; למערכת הכוננים נדרשת רמת שירות מתאימה ממדית האחסון. ללא אמינות מספקת בכל אחת משלוש הרמות האלה, תקלה הופכת להיות מצב אפשרי. ויש להגדיר בבירור את רמות השירות האלו , מאחר שברור שאין היגיון לטעון שמערכת קבצים עמידה לכשל אם התקני האחסון אינם אמינים. בכל שכבה של המערכת צריך שיהיה ברור מה המשמעות של אל–כשל עבור השכבה האמורה, ומה נדרש משכבות אחרות.
נתחיל בהגדרת הדרישות שאותם צריך המפתח להעמיד בפני זיכרון אל–כשל. ראשית עלינו לדעת במדויק את המשמעות של אל–כשל. בחברת HCC–Embedded אופיינו שתי תכונות עיקריות. האחת היא שבכל פעם שקובץ נכתב במערכת, פעולת סגירה או מחיקה שלו תעביר את מצבו הקודם למצב עקבי חדש. למעשה, ההחלטה לגבי העקביות נותרת בידי מפתח היישום. התכונה השנייה היא שבמקרה של אתחול לא צפוי במערכת, מערכת הקבצים תהיה קוהרנטית וכל הקבצים יהיו במצבם העקבי שלפני האתחול.
יש להדגיש את נקודת העקביות הזו, מאחר שבכל מערכת קבצים עליך לקבוע מתי הנתונים שנוספו תקפים, שכן, זה הזמן שבו צריך לעדכן את המטא–נתונים (metadata). כל פעולות הכתיבה למערכת הקבצים אינן מתקבעות (committed) בזיכרון עד ביצוע פעולת סגירה או מחיקה, שמציינת שיש להפוך את המצב החדש לתקף. באופן כזה, איש הפיתוח יכול לקבוע מהו מצב עקבי עבור המערכת. משמעות הדבר איננה שהנתונים לא נכתבו במדית היעד; המשמעות היא שהמטא–נתונים של הקובץ עדיין מתייחסים למצב העקבי הקודם, עד שהמפתח יחליט לשנות זאת. המשמעות היא גם שאם אתה מחפש לאחור בקובץ ואז כותב דבר מה על נתון, עליך לשמור עותק מקורי. כך מובטח שבקרות מקרה בלתי צפוי, מצב הקובץ יהיה תקף ועקבי. תאור פשוט זה הוא תמצית הגישה שמאפשרת מימוש מערכות קבצים אל–כשל שתהיינה באמת אמינות.
מערכות הקבצים של HCC–Embedded מתוכננות להשיג את הדרישות המוגדרות, אם כי רק אם הכוננים והמדיה הפיסית יעמדו בדרישות מסוימות. הדרישה האחת היא שעל הכונן לכתוב את הנתונים ברצף שהם מתקבלים. כלל זה מאלץ את הרצף הנכון גם כשמשתמשים בזיכרון מטמון, שכן אין אפשרות שסקטור ייכתב כאשר הסקטור הקודם טרם נשמר. הדרישה השנייה היא שבמקרה של אתחול פיסי או תקלת חשמל, כל סקטור חייב להיות כתוב, אחרת התוכן של הסקטור הישן יישאר התקף. אסור שיהיה מצב ביניים שבו התוכן של סקטור הוא בעצם אקראי. המעבר מהמצב הישן לחדש חייב להיות בלתי פריק (אטומי). אפשר לתכנן מערכות עם דרישות שונות, אך יש לתאר אותן בבהירות ולהבין אותן על מנת להגיע למטרת התכנון – אל כשל. דרישות אלו, שנראות פשוטות למדי, למעשה קשות להשגה בגלל התכנון של התקני האחסון. ספק כוח יציב ואיפוס נקי של המתח הם תנאים הכרחיים, במיוחד במערכות שבהן משולב זיכרון הבזק. חשוב שיהיה אבחון של ירידה במתח הרשת שמאפסת כרטיסי זיכרון ההבזק כשהמתח יורד אל מתחת לרמה מוגדרת. אין אפשרות להבטיח כתיבת נתונים אמינה ללא רמה סבירה של מתח האספקה. בעיות שונות עלולות להתרחש. למשל, פעולת כתיבה מסוימת יכולה להצליח בעוד זו שקדמה לה נכשלה, או שמופיעה תקלה בכתיבה או במחיקה, ועלולים להיווצר בלוקים תקולים במערכת. קיימים סוגים של כרטיסים מבוססי זיכרונות הבזק, שנפגעים באופן מלא ולצמיתות אם מורידים את מתח האספקה שלהם באיטיות כשהם במצב כתיבה. בכרטיסים אחרים משולבת יכולת אבחון מצבי ירידה של מתח האספקה כדי להימנע מכך.
הפתרון הברור מאליו עבור כל הבעיות האלו הוא לספק באופן אמין מתח להתקן. אין זה בהכרח פשוט כפי שזה נראה בתחילה. קשה לעתים לקבל מהיצרנים נתונים לגבי צורת ההתנהגות של נתונים בהתקן במהלך תקלת מתח. התוצאה היא, שלעתים, הגילוי הוודאי לגבי מהו הזמן של המצב הגרוע ביותר שנדרש לאחסון כל הנתונים שבשמירה, יכול להיות קשה. עבור התקנים של חלק מהיצרנים יש נתונים לגבי הזמן הזה, ולכן יש אפשרות לתכנן לפי המפרט שפורסם. ואולם, על אף שקיים פתרון ניתן למימוש עבור מקרים אלו, המבחר הופך להיות מוגבל במידת מה. אספקת מתח לא אמינה תערער את אמינותה של כל מערכת אל–כשל, שבמצב אחר הייתה נחשבת לאמינה. מעט מאוד יצרנים, בהם יוצאי דופן ספורים שראויים לציון, מכריזים באופן ברור על מאפייני הפעולה של התקני האחסון במונחים שיהיו שימושיים למתכנן מערכת אל–כשל אמיתית. חברת HCC הפעילה בדיקות קפדניות על כרטיסי זיכרון במצב מוצק, אשר קיימים בשוק המסחרי. הרוב המכריע שבהם הציג התנהגות לא אמינה. רק מספר קטן מבין הכרטיסים סווג כסביר לשימוש במערכות קבצים אל–כשל.
כוננים קשיחים (HDD) הם התקנים שקשה להשתמש בהם, במיוחד לא במערכות אמינות. הבעיה העיקרית היא שכולם מכילים זיכרון מטמון מובנה לנתונים, שבדרך כלל קשה לשלוט בו. אם היה קל לשלוט בזיכרון המטמון, הרי ששליטה כזו הייתה מצמצמת מאוד את ביצועי הדיסק. בין כל הכוננים שנבחנו, לא מצאנו אף לא אחד שלגביו יצאה הכרזה ברורה לגבי תרחיש המקרה הגרוע ביותר בעת כיבוי, וכמה זמן והספק נחוצים על מנת להבטיח שתוכן זיכרון המטמון ייכתב בבטחה בדיסק. אם אין אפשרות להבטיח את מחיקת זיכרון המטמון, הרי שקיימים תרחישים של המקרה הגרוע ביותר שבהם כמויות גדולות של נתונים יאבדו בעוד נתונים שייכתבו לאחר מכן יהיו תקינים.
לכרטיסי SD, לכרטיסי זיכרונות הבזק קומפקטיים ולכונני מצב מוצק יש מאפייני תכנון דומים. הם מכילים מערכים של התקני הבזק מסוג NAND, אשר מנוהלים על ידי שכבת תרגום הבזק (FTL), שמספק ממשק סקטורים לוגיים למערכת חיצונית. הפעולה של שכבות FTL נשמרת בסודיות רבה על ידי רוב היצרנים, אך ברור שכדי לקבל את הביצועים המרביים, רבים מבין ההתקנים משתמשים בטכניקות של שמירה בזיכרון מטמון ושל כתיבה מקבילית. התוצאה היא שבמקרה של איפוס בלתי צפוי, ייתכן שסקטורים ייכתבו מחוץ לרצף.
לזיכרון הבזק משולב יש יתרון גדול: תכנון המערכת נמצא אז כולו בשליטת המפתח. עם זאת, יש עדיין לנקוט זהירות. אם נבחן שוב את התרשים בשאלה אם יש ליצור ממשק בין זיכרון הבזק לבין המערכת, נראה שנדרש סוג כלשהו של שכבת ניהול זיכרון הבזק בין מערכת הקבצים לבין זיכרון ההבזק. בדרך כלל תהיה זו שכבת תרגום לזיכרון הבזק אשר משולבת בתוך כרטיס SD, כרטיס SSD ובכרטיס זיכרון הבזק קומפקטי. חשוב ששכבת FTL תתוכנן להיות מהסוג של אל–כשל, וכן שתהיה בקרה נכונה של אספקת המתח. לכל סוגי המדיה יש מוזרויות וחולשות אופייניות להם. עם זאת, עם הבנה מתאימה של התנהגות המדיה, שעלולה להיות מורכבת מאוד וחמקמקה למדי, אפשר ליצור מערכות אל–כשל.
מהם התנאים העיקריים שבעטיים עלולה מערכת קבצים להינזק? ראשית, כדאי לשים לב שמצב כזה יכול להתרחש רק כאשר פעולת כתיבה או מחיקה מתבצעות בהתקן המטרה. עם זאת, מצב זה יכול גם להיות התוצאה של פעולת המשתמש או של פונקצית ניהול, כגון מחיקה ברקע או איזון בלאי (wear levelling). שני האירועים העיקריים שעלולים לגרום לכשל במערכת הם (1) איפוס בלתי צפוי של המערכת כתוצאה מהיעלמות המתח או מתנאים אחרים של החומרה ו–(2) איפוס בלתי צפוי של המערכת כתוצאה משגיאת תוכנה (באג). לדוגמה, כוננים קשיחים מכילים בדרך כלל זיכרון מטמון פנימי גדול (8 מגה–ביית או יותר), כך שאם מתח הדיסק נעלם באופן בלתי צפוי, מערכת הקבצים עלולה לאבד נתונים מזיכרון המטמון ונתונים רבים עלולים להיכתב מחוץ לרצף. מערכת קבצים שטוענת שהיא אל–כשל צריכה להגדיר באמת במה היא יכולה לעמוד, ועדיין להישאר אל–כשל, ואז התכנון אמור לשקף זאת.
על מנת להבטיח מאפייני אל–כשל של מערכת הקבצים וגם להבין את הבעיות העולות מכך, ביצעה חברת HCC בדיקות נרחבות בשתי צורות עיקריות. הראשונה הייתה הדמיה. אפשר לבדוק את מערכת הקבצים כולה ואת הכוננים בהדמיה במחשב אישי. אפשר ליצור במהירות רבה מיליונים של פעולות איטרציה של תרחישי תקלה ואפשר לאמת את התכנון של מערכת הקבצים. השניה הייתה בדיקה במערכת משובצת. ברור שהדמיה לא בודקת את המערכת עם מדיית המטרה, וכפי שמתואר, חיוני ביותר להבטיח שהיא מספקת את איכות השירות הנדרשת. עובדה זו נכונה במיוחד כאשר יצרני ההתקן לא מספקים מידע מפורט בנוגע לאופן שבו התקן האחסון שלהם פועל. בדיקה זו מתבצעת על ידי שימוש במעגל חיצוני כדי לאפס באופן אקראי את מערכת המטרה. בכל אתחול, תוכנית אימות בודקת אם התוכן של המערכת ניזוק. בדיקות מקיפות שנערכו בכרטיסי SD רבים הראו שמעט מאוד מבין הכרטיסים עומדים בדרישות של כתיבה בלתי פריקה וברצף, ולכן, רובם אינם מתאימים כאשר יש חשיבות לנתונים.

*הכתבה נמסרה באדיבות חברת פרטק – אמבדד סלושנס

תגובות סגורות