קצת על SMART וכלי עזר לניטור

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

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

1) יש להשתמש בזהירות רבה בתוכנות לניטור אוטומטי של תכונות SMART.

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

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

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

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

ההצהרה על הגדלת הסיכונים אינה מסקנה תיאורטית, אלא התבוננות מעשית. לדוגמה, יש באג ידוע שהתרחש בקושחה של HDD Samsung 103UI, שבו נתוני המשתמש נפגעו במהלך תהליך בקשת תכונות SMART.

לכן, אין להגדיר בדיקה אוטומטית של תכונות SMART. אלא אם כן אתה יודע בוודאות שפקודת שטיפת המטמון (Flush Cache) מונפקת לפני זה. לחלופין, אם אינך יכול בלעדיו, הגדר את הסריקה כך שתפעל לעתים רחוקות ככל האפשר. בתוכניות ניטור רבות, זמן ברירת המחדל בין בדיקות הוא כ-10 דקות. זה נפוץ מדי. יחד עם זאת, בדיקות כאלה אינן תרופת פלא לכשל דיסק בלתי צפוי (תרופת פלא היא רק גיבוי). פעם ביום - אני חושב שזה די מספיק.

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

2) נתוני תכונות SMART לרוב אינם אמינים.

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

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

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

3) הפרשנות של אינדיקטורים SMART היא ספציפית לספק.

לדוגמה, בסיגייט אסור לשים לב לערכים הגולמיים ה"רעים" של תכונות 1 ו-7, כל עוד השאר נורמליים. בדיסקים של יצרן זה, הערכים האבסולוטיים שלהם עשויים לעלות במהלך שימוש רגיל.

כדי להעריך את מצבו ושאר חייו של הכונן הקשיח, מומלץ קודם כל לשים לב לפרמטרים 5, 196, 197, 198. יתרה מכך, הגיוני להתמקד בערכים מוחלטים, גולמיים, ולא בנתונים. . כפיית תכונות יכולה להתבצע בדרכים לא ברורות, שונות באלגוריתמים ובקושחה שונים.

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

מקור: www.habr.com