Журналирование

NTFS - відмовостійка система, яка цілком може привести себе в коректне стан при практично будь-яких реальних збої. Будь-яка сучасна файлова система заснована на такому понятті, як транзакція - дія, що здійснюється цілком і коректно або не здійснювати взагалі. У NTFS просто не буває проміжних (помилкових чи некоректних) станів - квант зміни даних не може бути поділений на до і після збою, приносячи руйнування і плутанину - він або досконалий, чи скасовано.

Приклад 1: здійснюється запис даних на диск. Раптом з'ясовується, що в те місце, куди ми тільки що вирішили записати чергову порцію даних, писати не вдалося - фізичне пошкодження поверхні. Поведінка NTFS в цьому випадку досить логічно: транзакція запису відкочується цілком - система усвідомлює, що запис не проведена. Місце позначаються як збійні, а дані записуються в інше місце - починається нова транзакція.

Приклад 2: більш складний випадок - йде запис даних на диск. Раптом, бах - відключається живлення і система перезавантажується. На якій фазі зупинилася запис, де є дані, а де чушь? На допомогу приходить інший механізм системи - журнал транзакцій. Справа в тому, що система, усвідомивши своє бажання писати на диск, позначила в метафайлі $ LogFile цей свій стан. При перезавантаженні це файл вивчається на предмет наявності незавершених транзакцій, які були перервані аварією і результат яких непередбачуваний - всі ці транзакції скасовуються: місце, в яке здійснювалася запис, позначається знову як вільне, індекси і елементи MFT наводяться в с стан, в якому вони були до збою, і система в цілому залишається стабільна. Ну а якщо помилка сталася при запису в журнал? Теж нічого страшного: транзакція або ще й не починалася (йде тільки спроба записати наміри її справити), або вже закінчилася - тобто йде спроба записати, що транзакція насправді вже виконана. В останньому випадку при наступному завантаженні система сама цілком розбереться, що насправді все і так записано коректно, і не зверне уваги на "незакінчену" транзакцію.

І все-таки пам'ятайте, що журнал роботи - не абсолютна панацея, а лише засіб істотно скоротити кількість помилок і збоїв системи. Навряд чи пересічний користувач NTFS хоч коли-небудь помітить помилку системи або змушений буде запускати chkdsk - досвід показує, що NTFS відновлюється в повністю коректне стан навіть при збоях в дуже завантажені дискової активністю моменти. Ви можете навіть оптимізувати диск і в самий розпал цього процесу натиснути reset - ймовірність втрат даних навіть у цьому випадку буде дуже низька. Важливо розуміти, однак, що система відновлення NTFS гарантує коректність файлової системи, а не ваших даних. Якщо ви проводили запис на диск і отримали аварію - ваші дані можуть і не записатися. Чудес не буває.

Транслятор у мові асемблер

Транслятором з мови Асемблер, або, коротше кажучи, асемблером, називається системна програма, яка переводить текст програми з мови Асемблера на машинну мову.

Для зручності розрізнення однойменних назв будемо назву транслятора писати з маленької літери, а назву мови – з великої літери.

У загальному випадку програма мовою Асемблер може містити команди мови Асемблер, макрокоманди і директиви мови Асемблер (псевдокоманди). Тому Асемблер мікропроцесорів Intel 80I86 є по суті мак­ромовою, і процес трансляції складається з двох стадій.

На першій стадії всі макрокоманди заміняються командами Асемблера. На другій стадії команди мови Асемблер переводяться в машинні коди, тобто здійснюється власне асемблювання.

На другій стадії в процесі трансляції вхідної програми асемблер виконує два перегляди (надалі проходи) вхідного тексту. Однією з основних причин цього є посилання вперед. Це здійснюється у тому випадку, коли в деякій команді є перехід на мітку, значення (величина зміщення) якої ще не визначено асемблером.

Під час першого проходу асемблер переглядає всю вхідну програму і будує таблицю символічних імен, які використовуються в програмі, тобто таблицю змінних, констант та міток програми і їх відносних адрес (зміщень).

Під час другого проходу, маючи в наявності всю необхідну інформацію, генерується об’єктна програма.