MBR и прочие радости жёсткого диска

Всем привет!
Возникло несколько вопросов, но смежных (про геометрию жёстких дисков и загрузочные области), к тому же, предполагающих простые ответы, поэтому буду спрашивать в одной теме...

1. Все ли диски имеют 63 сектора на дорожке? Или бывает меньше?
2. Всегда ли между MBR и первым разделом расстояние минимум 63 сектора (т.е. 62 сектора между ними)? Или бывает меньше (в каких-то системах)?
3. Возможно ли установить винду на диск с размером сектора, не равным 512 байт (и вообще, встречаются ли такие жёсткие диски?)
4. Встречается ли между MBR и первым разделом не нулевые заполнители, а какие-либо другие (скажем, из символов 255 или в виде повторяющихся слов а-ля 0x8000)? Кроме секторов со служебными данными, естественно.
5. Можно ли установить и успешно загружать винду с USB, имеющим формат не HDD-USB, а FDD-USB, т.е. с boot-сектором в начале, а не MBR? Полагаю, что как минимум Win95/98 можно.

2

1. Все ли диски имеют 63 сектора на дорожке? Или бывает меньше?
------------------------
У всех HDD 63-сектора в цилиндре (дорожке) вне зависимости от номера цилиндра. Нулевой цилиндр это внутренний по отношению к оси цилиндр, и он меньше диаметром, чем последний/внешний. По логике вещей, у внутренних и внешних дорожек должно быть разное кол-во секторов, и на самом деле это так. Но транслятор адреса в контроллёре берёт среднее число, которое и равно 63-сектора в дорожке.

2. Всегда ли между MBR и первым разделом расстояние минимум 63 сектора
------------------------
Да всегда. Любой раздел начинается только с нового цилиндра, для чего головка делает 1-шаг и пропускает 63-сектора.

3. Возможно ли установить винду на диск с размером сектора, не равным 512 байт (и вообще, встречаются ли такие жёсткие диски?)
------------------------
Размер сектора задаётся при форматировании диска, и любой форматер в служебном поле файловой системы делает отметку о размере сектора. Если это ни какой-нибудь редкий экземпляр, то по умолчанию размер сектора всегда равен 512-байт.

Если рассматривать в общем, то в наше время существует всего 3-стандарта разметки секторов: 512N/512E/4KN. Чистые 512-байт в секторе - это стандарт(512N), 4Kb-сектор с эмуляцией 512 называют(512Е). Ещё существует Advanced-Format(AF) в котором и логический и физический сектор равен 4Kb.

Формат AF введён для сжатия современных дисков, размеры которых превышают терабайтный предел. У всех гигантов обязательно присутствует поле ЕСС для коррекции ошибок. Для сектора в 512-байт под ЕСС отводится 50 байт. Если-же сектор расширить до 4096-байт, то длина ECC-поля составляет всего 100 байт, а ни как предполагалось 50*8=400 байт. Таким образом общую плотность хранения данных удалось улучшить примерно на 10%.

В любом случае, нестандартные сектора должна поддерживать как ОС, так и сам контроллёр диска. 4KN-разметку поддерживают все серверные системы, и десктопы начиная с Win-8. ХР и семёрка то видит 4Kb-сектора, только с их эмуляцией 512Е. Из-за проблем выравнивания, эта эмуляция создаёт немало головняков, поэтому применяется редко.

4. Встречается ли между MBR и первым разделом не нулевые заполнители, а какие-либо другие.
------------------------
Как-правило там всегда болото нулей.
Исключения могут составлять только случаи, когда раньше был установлен какой-нить расширенный загрузчик. Это левые загрузчики, которые позволяют выбирать при загрузке какую-нибудь ОС, если установлено несколько систем на одном диске. Мусор от таких загрузчиков остаётся даже после их удаления, поскольку при удалении просто меняется первый байт в файловой записи на F6h - остальные данные остаются на месте.

Я как-то проводил эксперименты с дискетой, и даже после её форматирования под загрузочную, обнаруживал на ней старые записи. Пробовал даже принудительно забивать дискету нулями в HEX-редакторе HxD, но старые файлы всё-равно всплывали, как феникс из пепла. Для меня это так и осталось загадкой.

5. Можно ли установить и успешно загружать винду с USB, имеющим формат не HDD-USB, а FDD-USB, т.е. с boot-сектором в начале, а не MBR? Полагаю, что как минимум Win95/98 можно.
------------------------
Думаю, что можно. Тебе-же главное загрузиться с неё, а дальше твой загрузчик передаст управление установшику мастдая и лоадер больше не потребуется. Проблема может возникнуть только на конечном этапе установки, когда установщику приспичит перезагрузится, чтоб прописать драйвера. Поэтому нужно опробовать в реальных условиях.

5

Тимур, спасибо! Ты, как всегда, тут главный спец железу

Сообщение от R71MT Да всегда. Любой раздел начинается только с нового цилиндра, для чего головка делает 1-шаг и пропускает 63-сектора.

Даже если это не винда, всё равно делают с 64-го сектора? Теоретически же можно сделать меньше.

Сообщение от R71MT Формат AF введён для сжатия современных дисков, размеры которых превышают терабайтный предел. У всех гигантов обязательно присутствует поле ЕСС для коррекции ошибок. Для сектора в 512-байт под ЕСС отводится 50 байт. Если-же сектор расширить до 4096-байт, то длина ECC-поля составляет всего 100 байт, а ни как предполагалось 50*8=400 байт. Таким образом общую плотность хранения данных удалось улучшить примерно на 10%. В любом случае, нестандартные сектора должна поддерживать как ОС, так и сам контроллёр диска. 4KN-разметку поддерживают все серверные системы, и десктопы начиная с Win-8. ХР и семёрка то видит 4Kb-сектора, только с их эмуляцией 512Е. Из-за проблем выравнивания, эта эмуляция создаёт немало головняков, поэтому применяется редко.

Интересно, а каков же тогда формат MBR ?
Получается, что первые 512 байт - это всё как положено, включая сигнатуру 55,AA, а дальше мусор?
И если я буду читать с такого диска 1 сектор через int 13h, то прочту 4 Кб?

Добавлено через 49 секунд
Кстати, а можно ли вообще заставить грузить систему через MBR, если включен UEFI? Ну, например, убрать раздел GPT из partition table? Или ещё как-то.
Не меняя настроек BIOS'а.

2

Сообщение от Jin X Даже если это не винда, всё равно делают с 64-го сектора?

Тут дело не в секторах, а в новом цилиндре. Раздел не может начинаться с середины цилиндра.

Сообщение от Jin X И если я буду читать с такого диска 1 сектор через int 13h, то прочту 4 Кб?

Нет. для INT13h сектор всегда равен 512-байт - это зашито в мозгах биоса.
C EFI особо не практиковался, поэтому точно сказать не могу.

3

Сообщение от R71MT Раздел не может начинаться с середины цилиндра.

Почему не может?
К тому же, в partition table есть же LBA-запись. Почему туда нельзя записать 20 или 50, скажем?

Сообщение от R71MT Нет. для INT13h сектор всегда равен 512-байт - это зашито в мозгах биоса.

А в чём тогда выражается разница между 512E и AF, если я всё равно вижу 512 и там, и там?
Или это проявится при прямом обращении к HDD (грубо говоря, через порты и пр.)?

Добавлено через 3 минуты
Про мозги BIOS'а. Т.е. получается, если сектор имеет размер 4 Кб, то при чтении 2-го сектора через int 13h я прочту по факту первый, но со смещением 512 ?

Кстати, а может ли случиться так, что при потере питания в момент записи сектора запишется только часть данных (ну или, к примеру, ECC не успеет записаться)? Или сектор всё равно успеет записаться "на конденсаторе"?

2

partition table есть же LBA-запись. Почему туда нельзя записать 20 или 50, скажем?

LBA - это только адресация, она не создаёт разделы.
А вот кто их создаёт, у того прописан жёсткий алгоритм, где сказано - "Начинать раздел с нового цилиндра". Если ты залезишь ручками в таблицу разделов и изменишь её под свой вкус, то системный "менеджер дисков" просто не определит разделы на твоём диске.

А в чём тогда выражается разница между 512E и AF

разницу видит только ОС. Для остальных сектор равен 512-байт

при потере питания в момент записи сектора запишется только часть данных

только часть данных.
При потере питания диск успеет только припарковать головки. Для таких случаев в его двигателе имеется специальная обмотка, которая служит генератором. Когда пропадает питание, диск ещё крутится какое-то время и с этой обмотки снимается напряжение, достаточное чтобы только припарковать головки в парковочную зону. На остальное его мощности уже не хватает.

3

Сообщение от R71MT только часть данных

Т.е. сектор не просто может оказаться недозаписанным, но и вообще иметь ошибку при попытке последующего чтения (из-за ошибки ECC), так?
А как дела в этом плане обстоят с SSD ?

Добавлено через 9 часов 2 минуты

Сообщение от R71MT системный "менеджер дисков" просто не определит разделы на твоём диске.

Что подразумевается под системным менеджером дисков? Виндовый?

2

Сообщение от Jin X А как дела в этом плане обстоят с SSD ?

SSD - из другой оперы. Это большая флэшка и у него нет подвижных частей.
В них применяется 2-типа памяти: DRAM-кэш, и запоминающая NAND-матрица. Имеется такой-же контроллёр как у HDD, благодаря которому эта флэшка и определяется как жёсткий диск, и поддерживает набор ATA-команд. Буферная кэш-память связывает диск с интерфейсом SATA на мат.плате.

NAND - это блочная память. Она устроена так, что весь объём разбивается на 4Kb страницы, с неё нельзя считать байт или 512-байтный сектор. Мин.порция чтения/записи - одна 4K-байтная страница по стандарту 4KN. Стирание вообще осуществляется 512К-байтными блоками. Такая картина предъявляет особые требования к контроллеру SSD, алгоритм работы которого зашивается в его ROM.

Операция чтения читает 4Kb-страницу целиком, а операция записи проблематична и происходит по такой схеме:

1. Считать модифицируемый 512Kb блок во внутренний кеш;
2. Изменить необходимые байты;
3. Стереть считанный блок в NAND-флэш (мин.512Kb);
4. Найти пустое место во флэш для изменённого блока (требование алгоритма перемешивания);
5. Записать 512K-байтный блок на новое место.

Пункт(4) в работе SSD-накопителей считается самым/больным местом. Проблема в том, что записанную информацию в NAND-памяти нельзя перезаписать до тех пор, пока не стерёшь старую. Только вот стереть можно как-минимум 512K блок, а не одну/модифицируемую страницу. Процесс стирания занимает много времени (в 15/20-раз больше, чем чтение), поэтому контроллёр не ждёт, а ищет пустой блок для модифицированных данных.

Следовательно, чем больше SSD забит полезными данными, тем чаще приходится прибегать к веткам[4:5] алгоритма, вместо прямой записи. По мере заполнения данными, в SSD наблюдаются тормоза, накопителю просто не хватает заранее стёртых блоков. Поэтому они работают быстро только пока новые (имеются чистые блоки), а в ходе их эксплуатации реальная скорость падает ниже плинтуса.

Для решения этой проблемы, в спецификации ATA-8 появилась новая команда 'DATA_SET_MANAGEMENT', более известная как TRIM. В периоды простоя, SSD самостоятельно осуществляет очистку и дефрагментацию блоков отмеченных как удаленные в ОС. Контроллер перемещает данные так, чтобы получить больше предварительно стертых ячеек памяти, освобождая место для последующей записи. Это дает возможность сократить задержки, возникающие в ходе работы.

Другая проблема в том, что в SSD лимитировано общее кол-во циклов стирания блоков.
Как и в USB-флэш, в SSD используются 3 типа NAND-памяти:
SLC-чипы намного дороже и они меньшего объёма. Для широкого паблика применяют в основном MLC/TLC-чипы. Чтобы увеличить срок службы, производители размазывают один блок по всем чипам-памяти и задействуют алгоритмы чередования. Кроме того, как и в HDD, в SSD имеется 20% резерва для замещения бэд-блоков.

На старых накопителях 'TRIM' может отсутствовать, нужно проверить его поддержку и при необходимости прошить контроллёр. Системы начиная с Win7/Linux-2.6.33 изначально поддерживают TRIM, для ХР необходимы спец.драйвера и утилиты типа 'SSD_Toolbox' (диагностика, SMART, оставшееся кол-во циклов стирания).

3

R71MT,
А если произойдёт сбой питания, что будет с блоком (из 512Kb) в SSD?

По логике (в целях безопасности) должно быть так:
1. Считываем 512K
2. Изменяем необходимые данные
3. Ищем пустое место
4. Записываем
5. Помечаем в карте блоков, что этот блок теперь находится на новом месте
6. Стираем старый

У тебя немного другой порядок (и п.5. отсутствует вообще).
Как на самом деле происходит?

2

Сообщение от Jin X Как на самом деле происходит?

это всё тонкости драйвера - зачем они тебе, ты драйвер пишешь?
если чисто для себя, то пункт(5) выполняется на автомате транслятором. До этих деталей программист не сможет дотянуться, т.к. алгоритм зашит в дисковый ROM-BIOS.

Проведём небольшой экскурс ссылаясь на доки..
Значит поиском в гугле нахожу картинку SSD-драйва и смотрю, какие в нём установлены чипы-памяти. Попадается диск с 8-чипами NAND-флэш 29F64G08CBAAB.



Теперь скачиваю даташит на этот чип и смотрю его характеристики:
Угу.. вот и организация..
64G в названии чипа указывает на его ёмкость, на рисунке 8-чипов значит этот SSD на 64x8=512Gb. Организация из даташита опровергает 4Kb-страницы - они разбухли до 8Kb, плюс сервисная 448-байтная зона. Помимо кодов ECC, в этой зоне имеется счётчик, который с каждым стиранием страницы увеличивается на 1.

Один NAND-блок состоит из 256-страниц, соответственно размер его 2Mb, а не 512Kb как в старых SSD-дисках. Именно такими блоками приходится оперировать контроллёру при записи/стирании данных. Страница читается макс за 50-микросекунд, а блок стирается уже за 3-миллисекунды, т.е. в 60-раз дольше. Польза от технологии Trim в этом случае очевидна, и описывается здесь: http://www.outsidethebox.ms/15016/



Среди 31-ой поддерживаемой ATA-команды, есть COPYBACK, которая позволяет перемещать данные внутри плоскости (Plane), с одной страницы на другую используя регистр-кэша. Это полезно для управления блоками и выравнивания износа, чем и занимается 'Trim'.

К каждому блоку пристыкована таблица трансляции и ряд маркеров (в частности, счётчик числа записей в блок), который обновляются одновременно с записью данных. Исправность служебных полей критически важна для доступа пользователя к данным, и здесь - на поверхность всплывает слабое место флеш-технологий..

Чтобы изменить даже один байт во флеш-памяти, надо прочитать блок в буфер, изменить байт, стереть и записать целый блок размером 2Mb. Любой сбой при записи (плохой контакт в разболтанном разъёме, нестабильное питание, дефектные ячейки на самой флешке и т.п.) может привести к ситуации, когда блок не успел записаться вместе со своими маркерами и таблицей трансляции. Целостность транслятора в этом случае нарушается, теряется правильная адресация памяти. Нужно сказать, что транслятор адреса у диска один, и хотя контроллёр в каждый момент времене имеет дело только с одним блоком, его запись модифицирует весь транслятор.

Это блокирует доступ пользователя к SSD, что внешне выглядит как сообщение типа "Устройство не опознано, RAW-формат" и т.п. С точки зрения контроллёра SSD, данная неисправность чисто программная и может быть вылечена путём стирания всего объёма памяти с созданием нового транслятора. Но как быть с данными?

Это обстоятельство объясняет, почему нельзя устанавливать систему на SSD-диск - ему судьбою предначертано быть хранителем данных, поскольку система постоянно что-то пишет на диск, насилуя его по-полной программе. Один файл-подкачки чего стоит..

5

Сообщение от R71MT это всё тонкости драйвера - зачем они тебе, ты драйвер пишешь?

Меня как раз-таки интересует что может быть при сбое питания.

Сообщение от R71MT Любой сбой при записи (плохой контакт в разболтанном разъёме, нестабильное питание, дефектные ячейки на самой флешке и т.п.) может привести к ситуации, когда блок не успел записаться вместе со своими маркерами и таблицей трансляции. Целостность транслятора в этом случае нарушается, теряется правильная адресация памяти. Нужно сказать, что транслятор адреса у диска один, и хотя контроллёр в каждый момент времене имеет дело только с одним блоком, его запись модифицирует весь транслятор. Это блокирует доступ пользователя к SSD, что внешне выглядит как сообщение типа "Устройство не опознано, RAW-формат" и т.п. С точки зрения контроллёра SSD, данная неисправность чисто программная и может быть вылечена путём стирания всего объёма памяти с созданием нового транслятора.

То есть сбой питания может убить данные на всём диске?

Добавлено через 1 час 0 минут

Сообщение от R71MT Это обстоятельство объясняет, почему нельзя устанавливать систему на SSD-диск - ему судьбою предначертано быть хранителем данных, поскольку система постоянно что-то пишет на диск, насилуя его по-полной программе. Один файл-подкачки чего стоит..

Ну вот у меня система как раз стоит на SSD. Более того, файл подкачки на нём же.
Диск Plextor M6 Pro (128 ГБ), MLC, т.е. примерно 10 тыс. стираний, а это ≈ 1280 ТБ.
Смотрим S.M.A.R.T. (Crystal Disk Info). Все показатели на отметке 100% здоровья.
За 3 года пользования значение поля E9 (NAND GB Written) показывает 37 415, т.е. 37 ТБ, что составляет менее 3% износа.
Полагаю, что это неплохо

2

Сообщение от Jin X Все ли диски имеют 63 сектора на дорожке? Или бывает меньше?

Ты пишешь софт для музея ЭВМ? Уже лет 25 все LBA используют.

Сообщение от Jin X Всегда ли между MBR и первым разделом расстояние минимум 63 сектора (т.е. 62 сектора между ними)?

Не всегда, можно вручную сделать меньше и в современных ОС все прекрасно будет работать. Обычно утилиты разметки по дефолту стараются эту область зарезервировать в целях совместимости. Но никаких гарантий нет. Это делалось для CHS геометрии, которую сейчас никто не использует.

Сообщение от Jin X Возможно ли установить винду на диск с размером сектора, не равным 512 байт (и вообще, встречаются ли такие жёсткие диски?)

Современные Win будут работать. Старые не уверен, хотя MS всегда уверяла, что не хардкодила свою дисковую подсистему на 512 байт. Таких дисков очень много. Многие современные SSD имеют размер сектора 4К.

Добавлено через 1 минуту

Сообщение от Jin X Встречается ли между MBR и первым разделом не нулевые заполнители, а какие-либо другие

Насколько я знаю, никаких требований к заполнению этих областей нет.

Добавлено через 2 минуты

Сообщение от Jin X Интересно, а каков же тогда формат MBR ?

Диски с 4К обычно используют GPT. Как заполняется MBR для нестандартных секторов - не помню.

Добавлено через 2 минуты

Сообщение от R71MT Если ты залезишь ручками в таблицу разделов и изменишь её под свой вкус, то системный "менеджер дисков" просто не определит разделы на твоём диске.

Я создавал разделы вообще без заполнения полей CHS и та же Винда их прекрасно видела.

Добавлено через 6 минут

Сообщение от R71MT и поддерживает набор ATA-команд

Обычно SCSI 2.0, а вообще протокол самого нижнего уровня, к сожалению, жестко не определен. Гуглим USB Mass Storage Device Class Bulk Only Transport specification. Я делал у себя поддержку только протокола SCSI для флешек и все устройсва, которые у меня побывали на руках, заработали по нему. Но я точно знаю, что существуют USB HDD, которые ожидают Packet (generic) ATA.

3

Сообщение от Jin X 4. Встречается ли между MBR и первым разделом не нулевые заполнители, а какие-либо другие

Гы, гы. В стародавние времена такими заполнителями были загрузочные вирусы. И все прекрасно работало. В смысле размножалось.
Точнее сам вирус был в первом секторе дорожки, но оригинальный сектор MBR он всегда сохранял в одном из неиспользуемых секторов той-же дорожки. Отсюда и лечение от загрузочного вируса было простым - найти в каком секторе 0-й дорожки вирус сохранил оригинальный MBR и записать его обратно, на положенное ему место.

Добавлено через 10 минут

Сообщение от Jin X 1. Все ли диски имеют 63 сектора на дорожке? Или бывает меньше?

Бывает. У винтажных. Например MFM-овский ST225 на 20 мегабайт. У него 615 дорожек, 4 бошки и 17 секторов на дорожку.
63 сектора в дорожку стало повсеместно когда объемы дисков подошли где-то к пол гига (если опять таки не склероз) и с тех пор 63 сектора везде.

Добавлено через 8 минут

Сообщение от Jin X Получается, что первые 512 байт - это всё как положено, включая сигнатуру 55,AA, а дальше мусор?

Если не склероз у Win-98 MBR-загрузчик уже не влезал в 1 сектор и занимал два. Первый сектор загрузчика подчитывал второй. Загрузчики с мультизагрузкой разных ОС тоже небось занимают несколько подряд секторов на 0-й дорожке. Не запихать их в один сектор уже. Так-что свободные сектора на нулевой дорожке - это благо.

Добавлено через 6 минут
Короче мысль такая - в первом секторе нулевой дорожки должен быть MBR, а в остальных может быть что попало.

2

Сообщение от shmkv Обычно SCSI 2.0, а вообще протокол самого нижнего уровня, к сожалению, жестко не определен.

я брал из доки на чип SSD диска.
там указан протокол ONFI - Open_NAND_Flash_Interface. возможно они во-многом совпадают.
в списке идёт всего 31-команда по такому типу:

Миниатюры

 

0

Сообщение от Ethereal Первый сектор загрузчика подчитывал второй.

я в своём загрузчике размещал во-втором секторе картинку, получался загрузчик с граф.интерфейсом

0

P.P.S. Выше я привер пример MFM-диска (у них почему-то всегда было 17 секторов в дорожку). А вот винтажный IDE
Miniscribe (Maxtor) 8051A на 40 Mb
мы эту марку называли Минишкрябами
745 дорожек, 4 головки, 28 секторов в дорожку

1

Сообщение от Ethereal Короче мысль такая - в первом секторе нулевой дорожки должен быть MBR, а в остальных может быть что попало.

Под заполнителем я имею в виду не мусор/вирус/часть загрузчика и т.п., а одинаковые байты. Т.е. когда весь сектор заполнен, скажем, байтами 0E6h.

Добавлено через 3 минуты
Теоретически понятно, что всё возможно.
Суть вот в чём. При необходимости записи в MBR логично сохранять оригинал не тупо во 2-й сектор, а искать "свободный".
Под свободным можно подразумевать либо заполненный 0-ми, либо заполненный одинаковыми байтами (или даже словами).
Есть ли смысл искать не нули? Хотя поскольку это совсем незначительно усложняет процесс поиска такого сектора и восстановления "того", что было, есть смысл искать просто повторяющиеся слова, а не просто нули. ИМХО.

Добавлено через 4 минуты
А про кол-во секторов до первого раздела я спрашиваю для того, чтобы определить границы поиска этих "свободных секторов". Т.е. всегда ли искать в первых 63-х (62-х после первого) или иногда брать меньше. В принципе, можно считывать partition table и находить минимальный номер начального сектора среди всех разделов. И если там нет номера, меньшего, чем 63 (в LBA-формате, т.е. начиная с 0), тогда искать среди 62-х (после MBR).

Добавлено через 1 минуту
Кстати, если int 13h всегда считывает 512-байтовые секторы (даже для 4K-секторных дисков), тогда размер сектора, возвращаемый функцией 48h (информация о диске) будет всегда 512? Или там может быть 4096, но считываться всё равно будет 512 байт?

Добавлено через 1 минуту
И повторю ещё раз вопрос:

Сообщение от Jin X Т.е. получается, если сектор имеет размер 4 Кб, то при чтении 2-го (если считать с 1) сектора через int 13h я прочту по факту первый, но со смещением 512 ?

2

Сообщение от Jin X Или там может быть 4096, но считываться всё равно будет 512 байт?

вообще-то, у тебя есть-же SSD диск.
Открой его в хекс редакторе HxD и скопируй нулевой сектор.
Интересно было-бы посмотреть, что там в MBR и как указывается геометрия.

Добавлено через 2 минуты

Сообщение от Jin X есть смысл искать просто повторяющиеся слова, а не просто нули.

хорошая идея!

1

Сообщение от R71MT Открой его в хекс редакторе HxD и скопируй нулевой сектор.

Он показывает по 512 байт (обычный MBR, только без кода, ибо UEFI). Скорее всего, он открывает диск через CreateFile и читает порциями по 512 байт.
Хотя не так давно грузился с флешки, он показывал диск как содержащий 512-байтные секторны.

1

Сообщение от Jin X Суть вот в чём. При необходимости записи в MBR логично сохранять оригинал не тупо во 2-й сектор, а искать "свободный". Под свободным можно подразумевать либо заполненный 0-ми, либо заполненный одинаковыми байтами (или даже словами). Есть ли смысл искать не нули?

Нет никакого.

Добавлено через 5 минут
Если ты конечно не хочешь зачем-то сохранить возможность откатить старый MBR назад.
Только зачем такая возможность ? Загрузочному вирусу такая необходимость была нужна чтобы организовать стелс-режим и подставлять при чтении старый MBR, чтобы затруднить свое обнаружение. А в твоем случае какой резон ?

1