האם נתונים על כוננים קשיחים לשדרג ללא אזהרה על הנזק?
כולנו דואגים לשמור על הנתונים והקבצים שלנו בטוחים ושלמים, אבל האם זה אפשרי עבור נתונים להיות פגום ולקבל גישה על ידי משתמש ללא הודעה או אזהרה מכל סוג שהוא על הבעיה? היום של SuperUser Q & A פוסט יש את התשובה לשאלה מודאג של הקורא.
מפגש השאלות והתשובות של היום מגיע אלינו באדיבות SuperUser - חלוקה מחודשת של Stack Exchange, קיבוץ מונחה על ידי הקהילה של אתרי אינטרנט של Q & A.
תמונה באדיבות generalising (Flickr).
השאלה
SuperUser הקורא topo morto רוצה לדעת אם נתונים על כוננים קשיחים יכולים להשפיל ולקבל גישה ללא אזהרה על הנזק:
האם זה אפשרי כי השפלה פיזית של כונן קשיח עלול לגרום סיביות "להעיף" בתוכן של קובץ ללא מערכת ההפעלה להבחין בשינוי להודיע למשתמש על זה בעת קריאת הקובץ? לדוגמה, האם "p" (01110000 בינארי) בקובץ טקסט ASCII משתנה ל- q (בינארי 01110001), ולאחר מכן כאשר משתמש פותח את הקובץ, הם רואים את "q" מבלי להיות מודעים לכישלון?
אני מעוניין בתשובות הנוגעות ל- FAT, NTFS או ל- RFS (אם זה משנה). אני רוצה לדעת אם מערכות ההפעלה מגנות על המשתמשים, או אם אנחנו צריכים לבדוק את הנתונים שלנו לגבי שונות בין עותקים לאורך זמן.
האם נתונים על כוננים קשיחים מתדרדרים וניתן לגשת אליהם ללא אזהרה על הנזק?
התשובה
תורם SuperUser Guntram Blohm יש את התשובה עבורנו:
כן, יש דבר שנקרא ריקבון קצת. אבל לא, זה לא ישפיע על המשתמש מעיניהם.
כאשר כונן קשיח כותב מגזר על platters, זה לא רק לכתוב את סיביות באותו אופן שהם מאוחסנים RAM, הוא משתמש קידוד כדי לוודא שאין רצפים של אותו סיביות כי הם ארוכים מדי. זה גם מוסיף קוד ECC המאפשרים לתקן שגיאות המשפיעות על כמה סיביות וזיהוי שגיאות המשפיעות יותר מאשר כמה סיביות.
כאשר הכונן הקשיח קורא את הסקטור, הוא בודק את קודי ECC אלה ותיקן את הנתונים אם יש צורך (ואם אפשר). מה שקורה לאחר מכן תלוי בנסיבות הקושחה של הכונן הקשיח, אשר מושפע ייעודו של הכונן.
- אם ניתן לקרוא מגזר ואין לו בעיות קוד ECC, הוא מועבר למערכת ההפעלה.
- אם ניתן לתקן את הסקטור בקלות, ייתכן שהגרסה המתוקנת תיכתב לדיסק, תקרא שוב, ולאחר מכן תאומת כדי לקבוע אם השגיאה הייתה אקראית (כלומר, קרניים קוסמיות וכו ') או אם קיימת שגיאה שיטתית עם המדיה.
- אם הדיסק הקשיח קובע שקיימת שגיאה בתקשורת, הוא מחזיר מחדש את המגזר.
- אם מגזר יכול להיות לא לקרוא ולא לתקן לאחר כמה ניסיונות לקרוא (על כונן קשיח המיועד כמו כונן קשיח RAID), אז הכונן הקשיח יוותרו, להקצות מחדש את המגזר, ולומר הבקר כי היתה בעיה . זה מסתמך על בקר RAID לשחזר את הסקטור מחברי RAID אחרים ולכתוב אותו בחזרה לכונן הקשיח נכשל, אשר לאחר מכן מאחסן אותו במגזר שהוקצה מחדש (בתקווה אין בעיה).
- אם סקטור לא ניתן לקרוא או לתקן על הכונן הקשיח של שולחן העבודה, ולאחר מכן את הכונן הקשיח יעסוק בניסיונות נוספים לקרוא אותו. תלוי באיכות של הכונן הקשיח, זה עשוי להיות כרוך repositioning את הראש, לבדוק אם יש כמה סיביות כי להעיף כאשר לקרוא שוב ושוב, לבדוק אילו סיביות הם החלשים, ועוד כמה דברים. אם כל הניסיונות הללו יצליחו, הכונן הקשיח יקצה מחדש את הסקטור ויכתוב את הנתונים המתוקנים.
זהו אחד ההבדלים העיקריים בין כוננים קשיחים שנמכרים כמו "שולחן העבודה", "NAS / RAID", או "מעקב וידאו" כוננים קשיחים. כונן קשיח RAID יכול פשוט לוותר במהירות ולהפוך את הבקר לתקן את המגזר, כדי למנוע חביון בצד של המשתמש. כונן קשיח שולחני ימשיך לנסות שוב ושוב כי בעל המשתמש לחכות כמה שניות הוא כנראה טוב יותר מאשר לספר להם את הנתונים הוא איבד. ואת הכונן הקשיח וידאו ערכי נתונים קבועים יותר מאשר התאוששות השגיאה כמסגרת פגומה בדרך כלל אפילו לא שם לב.
בכל מקרה, הכונן הקשיח יידע אם יש כבר קצת ריקבון, יהיה בדרך כלל להתאושש ממנו, ואם זה לא יכול, זה יגיד הבקר אשר בתורו לספר לנהג אשר לאחר מכן לספר את מערכת ההפעלה. לאחר מכן, זה תלוי במערכת ההפעלה כדי להציג את השגיאה למשתמש ולפעול על זה. זו הסיבה cybernard אומר:
- אני מעולם לא עדים שגיאה אחת בודדת בעצמי, אבל ראיתי המון כוננים קשיחים שבו כל המגזרים נכשלו.
הכונן הקשיח יידע אם יש משהו לא בסדר עם מגזר, אבל הוא לא יודע איזה סיביות נכשלו. סיבית אחת נכשלה תמיד ייתפס על ידי ECC.
שים לב כי chkdsk ומערכות הקבצים לתקן באופן אוטומטי את עצמם לא כתובת תיקון נתונים בתוך קבצים. אלה מכוונים לשחיתות בתוך המבנה של מערכת הקבצים עצמה, כמו הבדל בגודל הקובץ בין ערך המדריך למספר בלוקים שהוקצו. תכונת הריפוי העצמי של NTFS תגלה נזק מבני ותמנע ממנו להשפיע על הנתונים שלך, אך היא לא תתקן נתונים שכבר נפגעו.
יש, כמובן, סיבות אחרות מדוע נתונים עלולים להיפגע. לדוגמה, RAM רע בבקר עשוי לשנות נתונים לפני שהוא נשלח אפילו לכונן הקשיח. במקרה זה, שום מנגנון בכונן הקשיח לא יזהה או יתקן את הנתונים, וזו עלולה להיות סיבה אחת מדוע המבנה של מערכת קבצים פגום. סיבות אחרות כוללות באגים בתוכנה, הפסקות חשמל בעת כתיבה על הכונן הקשיח (אם כי זה מטופל על ידי יומן מערכת קבצים), או מנהלי מערכת קבצים גרועים (הנהג NTFS על לינוקס ברירת המחדל לקריאה רק במשך זמן רב מאז NTFS היה מהונדסים לאחור, לא מתועד, היזמים לא סמכו על הקוד שלהם).
- היה לי תרחיש זה פעם שבו יישום היה לשמור את כל הקבצים שלה לשני שרתים שונים בשני מרכזי נתונים שונים על מנת לשמור עותק עובד של הנתונים הזמינים בכל הנסיבות. לאחר מספר חודשים, שמנו לב כי כ 0.1 אחוז מכלל הקבצים שהועתקו לא תואמים את סכום ההמחאה MD5 כי היישום מאוחסן במסד הנתונים שלה. זה התברר להיות כבל סיב פגום בין השרת לבין SAN.
אלה סיבות אחרות מדוע כמה מערכות קבצים, כמו ZFS, לשמור מידע נוסף לבדוק סכום על מנת לזהות שגיאות. הם נועדו להגן עליך מפני הרבה יותר דברים שיכולים להשתבש מאשר רק ריקבון קצת.
יש לך משהו להוסיף להסבר? נשמע את ההערות. רוצה לקרוא תשובות נוספות ממשתמשים אחרים בעלי ידע טכנולוגי מתמצא? בדוק את נושא הדיון המלא כאן.
