דף הבית » איך ל » מה עושה 'אימות דיסק' למעשה לעשות לאחר שריפת כדי לאמת את הנתונים?

    מה עושה 'אימות דיסק' למעשה לעשות לאחר שריפת כדי לאמת את הנתונים?

    התכונה 'אימות דיסק' היא דבר נהדר כדי לוודא שהדיסקים ששרפתם טרי התברר היטב, אבל איך בדיוק זה עובד? היום של SuperUser Q & A פוסט יש את התשובה לשאלה הקורא סקרן.

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

    צילום באדיבות cobalt123 (פליקר).

    השאלה

    SuperUser הקורא user130128 רוצה לדעת כיצד הדיסקים מאומתים לאחר שריפתם:

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

    אני מתכוון, זה יוצר חשיש של מקור ותוכן היעד, ואז משווה אותם? אם כן, האם זה לאחסן את חשיש של תוכן שרוף ב- RAM? או האם זה לשמור אותו בקובץ זמני על הכונן הקשיח? האם יש קובץ יומן של מה שקורה?

    רק סקרן לדעת בדיוק איך זה עובד תכונה. ואני מתכוון Windows Image Burner.

    כיצד פועל תהליך אימות הדיסק?

    התשובה

    SuperUser התורמים פרנק תומאס ו Synetech יש את התשובה עבורנו. ראשית, פרנק תומאס:

    בדוק את דפי MSDN האלה ב- Windows API עבור ממשק IBurnVerification ואת ה- IMAPI_BURN_VERIFICATION_LEVEL.

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

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

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

    ואחריו התשובה מאת Synetech:

    פרנק הסביר היטב את האימות הספציפי ל- Windows. אני אתן תשובה כללית יותר.

    • מה עושה אימות דיסק לאחר שריפת למעשה לעשות כדי לאמת את הנתונים?
    • אני מתכוון, זה יוצר חשיש של מקור ותוכן היעד, ואז משווה אותם? אם כן, האם זה לאחסן את חשיש של תוכן שרוף ב- RAM? או האם זה לשמור אותו בקובץ זמני על הכונן הקשיח? האם יש קובץ יומן של מה שקורה?

    זוהי בהחלט אחת הדרכים ההשוואה ניתן ליישם: hash קובץ אחד (בתקווה עם סיכוי גדול מספיק לקרוא את האלגוריתם של התנגשות), לחזור על השני, ולהשוות hashes. אם זה איך האימות מיושם, אז אתה יכול לראות את flash-LED flash למשך זמן מה, ולאחר מכן את הבזק CD / DVD LED במשך זמן מה.

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

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

    • אני מתאר לעצמי שזה קצת השוואה בין הקבצים המקוריים לבין הקבצים שנשרפו על הדיסק, אבל האם מישהו יודע איך זה באמת נעשה ברמה נמוכה?

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

    ניתן לראות אם ההשוואה מתבצעת מהכונן או מהמטמון ב- RAM על ידי כמה מהר זה קורה. אם אתה עושה ידנית השוואה פשוטה (כלומר עם WinDiff, WinMerge, או על ידי hashing אותם עם כלי hashing), תבחין כי ההשוואה קורה הרבה יותר מהר מהצפוי כי זה קורא את הקבצים מטמון זיכרון. עליך לשטוף את המטמון כדי לאלץ אותו לקרוא מהדיסק בפועל. עבור כוננים אופטיים (ואמצעי אחסון נשלפים אחרים כגון כונני flash וכרטיסי זיכרון), פשוט להוציא את הכונן מספיק כדי לשטוף את המטמון, אבל עבור כוננים קשיחים, זה לא כמעט פשוט (אם כי בדרך כלל זה לא משנה כי עותק חדש הוא זה שאתה רוצה לבדוק).


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