האם נתונים על כוננים קשיחים לשדרג ללא אזהרה על הנזק?

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

השאלה של היום &מפגש תשובה מגיע אלינו באדיבות SuperUser - חלוקה של סטאק שערי, קהילה מונחה קיבוץ של Q & אתרי אינטרנט.

תמונה באדיבות generalising( Flickr).

השאלה

SuperUser הקורא topo morto רוצה לדעת אם נתונים על כוננים קשיחים יכולים להשפיל ולהיות גישה ללא אזהרה על הנזק:

האם זה אפשרי כי השפלה פיזית של כונן קשיח עלול לגרום סיביות "להעיף" בתוכן של קובץמבלי שמערכת ההפעלה תשגיח על השינוי ותודיע למשתמש על כך בעת קריאת הקובץ?לדוגמה, האם "p"( 01110000 בינארי) בקובץ טקסט ASCII משתנה ל- q( בינארי 01110001), ולאחר מכן כאשר משתמש פותח את הקובץ, הם רואים את "q" מבלי להיות מודעים לכישלון?

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

האם נתונים על כוננים קשיחים מתדרדרים ונגישים ללא אזהרה על הנזק?

תשובה

SuperUser תורם Guntram Blohm יש את התשובה עבורנו:

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

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

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

• אם ניתן לקרוא מגזר ואין לו בעיות קוד ECC, הוא מועבר למערכת ההפעלה.
• אם ניתן לתקן בקלות את הסקטור, ייתכן שהגרסה המתוקנת תיכתב לדיסק, תקרא שוב, ולאחר מכן תאומת כדי לקבוע אם השגיאה הייתה אקראית( קרי, קרניים קוסמיות וכו ') או אם קיימת שגיאה שיטתית עם המדיה.
• אם הדיסק הקשיח קובע שקיימת שגיאה בתקשורת, הוא מחזיר מחדש את הסקטור.
• אם לא ניתן לקרוא ולא לתקן מגזר לאחר מספר ניסיונות קריאה( בכונן קשיח המיועד לכונן קשיח מסוג RAID), אזי הכונן הקשיח יוותר, יקצה מחדש את הסקטור ויגיד לבקר כיבְּעָיָה.זה מסתמך על בקר RAID לשחזר את הסקטור מחברי RAID אחרים ולכתוב אותו בחזרה לכונן הקשיח נכשל, אשר לאחר מכן מאחסן אותו במגזר reallocated( בתקווה אין בעיה).
• אם לא ניתן לקרוא או לתקן את הסקטור בכונן הקשיח של שולחן העבודה, אזי הכונן הקשיח יעסוק בניסיונות נוספים לקרוא אותו.בהתאם לאיכות של הכונן הקשיח, זה עשוי להיות כרוך repositioning את הראש, לבדוק אם יש כמה סיביות כי להעיף כאשר לקרוא שוב ושוב, לבדוק אילו סיביות הם החלשים, ועוד כמה דברים.אם כל הניסיונות הללו יצליחו, הכונן הקשיח יקצה מחדש את הסקטור ויכתוב את הנתונים המתוקנים.

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

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

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

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

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

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

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

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

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