פתרון הגנה על מערכת¶
דוגמת תקלה טובה היא reply שנשלח לפני fsync. הסימפטום הוא לקוח שקיבל הצלחה אך אינו מוצא תוצאה אחרי קריסה בתנאים המתאימים. ה־trace מראה את סדר הקריאות, והקוד מסביר מדוע שכבת הפרוטוקול קיבלה תוצאה לפני שרכיב האחסון התחייב. התיקון מעביר את נקודת יצירת התוצאה המאושרת לאחר sync ומוסיף בדיקת כשל בין שתי הנקודות.
בדוגמת ביטול, ה־trace לבדו עשוי לא להראות use-after-return לוגי. נשתמש ב־barrier ובמונה permits כדי להוכיח שהעבודה החוסמת עדיין חיה אחרי ביטול הממתין. התיקון מעביר את permit ואת ה־buffer ל־closure של הפעולה החוסמת, ומחזיר אותם רק בתוצאת ההשלמה. הבדיקה תוודא שאי אפשר לקבל עוד עבודה מעבר לתקציב בזמן שהפעולה הישנה תקועה.
הרחבה של group commit תאסוף כמה רשומות, תכתוב אותן ותבצע sync אחד. היא תשמור רשימת בקשות שממתינות לאותו commit, ותפרסם replies רק אחרי הצלחה. במקרה sync שנכשל כולן יקבלו תוצאה לא ודאית או כשל לפי החוזה, והאחסון יעבור למצב שמחייב recovery. הבדיקות הישנות של deduplication ושל prefix recovery ממשיכות לחול, ונוספת בדיקה שלא נשלח reply של קבוצה מאוחרת לפני שהקבוצה שלה עמידה.
הצגה טובה תציין גם מגבלה: trace של process kill אינו מדמה לבדו אובדן חשמל, ובדיקת זיכרון שאינה מוצאת כשל אינה מוכיחה שכל interleaving נבדק. המגבלות אינן פטור מבדיקה; הן מגדירות איזו ראיה נוספת נדרשת כדי להרחיב את ההבטחה.