כיצד מערכות קבצים מונעות אובדן מידע?

[lavifighter]

כיצד מערכות קבצים מונעות אובדן מידע?

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

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

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

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

*אני יודע שיש בווינדוס אופציה של הקפאת מערכת הקבצים וכתיבה הצידה במערכות כמו SQL וEXCH באמצעות VSS, ושיש מערכות כמו אורקל עם מערכות לוגים משלהן. אני מדבר על מקרים שבהם לא עשו שינוי במיוחד באפליקציה.

 

[DuuGi]

אתה יורה לכיוון הלא נכון.

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

 

[lavifighter]

לא דיברתי על בקרי רייד, דיברתי על משהו אחר

הכוונה שלי היתה לדברים ששומרים בRAM לעומת דברים שנכתבו כבר לדיסק-קיצר עניין הbufferים שקיים בלינוקס ואני מאמין שגם בווינדוס.

 

[DuuGi]

ואני עניתי גם על זה

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

 

[lavifighter]

אז אם יש מידע רב בRAM יכול להיות שחלק מהמידע ילך?

אם הוא לא יספיק להיכתב לדיסק בזמן כיבוי החשמל(או כל תקלה פיזית אחרת?).
קיצר, זה תלוי לפי מה שאתה אומר הרבה באפליקציה.
מה שזה לא מסביר זה למה יש אפליקציות ומערכות הפעלה שנחשבות crash consistent(כלומר לקיחת snapshot ברגע מסוים ברמת האחסון או הVM ללא דיבור על הguest os יהיה קונסיסטינטי והשרת יעלה ממנו), ויש כאלו שלא(למשל SQL וEXCH שחייבות להיות במצב vss?

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

בכל מקרה, תודה.

 

[idos2]

יש פה משהו נוסף שלא הוזכר

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

 

[lavifighter]

אנסה להסביר את הflow ששאלתי לגביו

אתה צודק ב100%.
תחשוב על התרחיש הבא(שוב אני לא מומחה לWEB או DB אז ייתכן שאני טועה פה ושם):
1. לקוח מעלה משהו דרך איזה ממשק WEB.
2. שרת הWEB כותב את המידע לשרת הDB בדרכים הידועות(למי שעוסק בDB כלומר לא לי), מאמין שהמידע נמצא אצל שרת הWEB רק בRAM אבל אין פה ACK).
3. שרת DB כותב את המידע לRAM ואולי גם לדיסקים(או מערך אחסון לצורך העניין, ועזבו ווירטואליזציה).
4. שרת הDB מקבל ACK.
5. שרת הWEB מקבל ACK.
6. הלקוח מקבל אישור שהפעולה בוצעה.
&nbsp
ה"חור" מבחינתי סעיפים 3-4: האם הACK מתקבל לאחר הכתיבה לדיסקים מצד השרת או לRAM מצד השרת? אני לא מדבר על nvram של מערך האחסון או דברים כאלה, אלא הRAM של השרת. ואיפה פה משתלב הjournal?
*במידה ובDB זה לא עובד ככה(שכן DB מאוד כבד מבחינת IO ככה שאני לא בטוח שככה זה עובד), אז תחליפו את הWEB במשהו שהוא front end ואת הDB בbackend.

 

[F00D Is G00D]

כמו שדודי רמז, המיינדסט של סטורג ו nvram הוא שגוי

עד שהכתיבה ל transaction log של ה db לא בוצעה, האפליקציה - ואם נכתבה נכון אז גם הקליינט, לא ייקבלו אישור. (וזה בין הייתר למה הוא קיים ולא כותבים ישר ל db אחרי איזשהיא המתנה בזיכרון) הבעיה מתחילה כשיש כל מני פתרונות קאש, והמאמר הבא מסביר את זה, ומקשר למאמרים אחרים רלוונטיים. https://support.microsoft.com/en-us/kb/234656 מה קורה בסביבה שהיא לא db?. קרה לך שמסמך וורד שפתחת שוחזר? בד"כ זה לא יכלול בדיוק את המידע up to the moment אלא כמה פעולות אחורה. זה בדיוק מה שהיה בזיכרטן הנדיף\נכתב חלקית והושמד. (מה ששוחזר זה מה שנשמר בקובץ המוסתר שנוצר בכל פתיחה לכתיבה של קובץ אופיס) קרה שהעלייה של ווינדוס נתקעה לעשר דקות על צ'ק דיסק? זה מה שוקרה כשמערכת הקבצים נתקעה באמצע הכתיבה. וזה בגדול מה שמחשבים היום יודעים לעשות. אין קסם, אין גיבוי לכל תרחיש. אין מקום להשוות את זה עם nvram של סטורג' או פתרונות קאש. ההבדל הוא שאותם פתרונות מאשרים את הכתיבה ללקוח הסופי. ואילו בכל אפליקציה נורמאלית אחרת הלקוח יודע שהמידע לא נשמר אם הוא לא עשה save או קיבל חיווי על כך שהוא נשמר. במקרה הכי קיצוני - פיננסים נוהגים לעשות גם רפליקציה סינכורנית הן ברמת ה db והן בסטורג'. עד ששניהן לא נשמרו (למעשה בטור), הלקוח הסופי לא ייקבל אישור עסקה. ופה יש רגולציה, זה לא שמישהוא ייכתוב עקום אפליקציה רק בשביל ביצועים (להיפך, הוא ייכתוב עקום ויידפוק ביצועים, לפעמים לשני db שונים, רק בשביל להבטיח שלמות של המידע)

 

[lavifighter]

ואיפה תפקידו של הjournal בכל העסק?