HDD: Продолжение темы с 746.52Gb на 3TB+ HDD
*** (Кратко) важно: BIOS на системе, где это будет проявляться, должен быть UEFI (сам по себе, при этом использоваться может как legacy).
Правильная формула для расчета смещения мусора.
Ну вот, наконец-то какая-то гадина опять записала в мои файлы. Из того, что я помню, что я делал "неординарного" - это запускал утилиту для просмотра SMART'а на всех дисках.
На зашифрованном диске записано прямо по Physical Disk (т.е. на зашифрованные сектора лег plaintext и при маунте/дешифрации вместо них отображается набор мусора -- дешифрация незашифрованного).
На всех остальных (незашифрованных) дисках - GPT / EFI PART, бэкап таблицы (при этом в последний сектор записано только 60h байт (96), т.е. не тронуто -- именно не тронуто -- 01A0h байт (416 байт), т.е. общий объем записанного 4200h - 01A0h = 4060h (16'480) байт. Остаточные 01A0h байт остались нетронутыми (прежние данные, мои сигнатуры).
Испорчено на всех дисках, кроме одного: [0x1x2x3]. Он остался с моими сигнатурами.
Сейчас восстановлю свои сигнатуры и попробую запустить эту утилиту опять.
Важно, что ядро ОС точно не влияет. В смысле, обновление не помогло.
Очень хорошо, что я понял проблему и сделал псевдо-бэд-сектора, иначе бы опять неизвестные файлы побились :)
Обновлено (ночь 27.08): Запуск двух SMART-тулз пока ни на что не повлиял. Гхм. Сейчас попробую поковырять в сторону фильтра диска.
Обновлено (день 27.08): С утра случился BSOD в iaStorA.sys (к вопросу качества драйверов Intel и к вопросу качества тестирования драйверов со стороны Microsoft - такое просто не допустимо), раз система перезагрузилась, решил заодно проверить файлы с левыми секторами. Посмотрел. Опять переписано поверх на нескольких дисках (на одном точно не переписано -- и это опять диск [0x1x2x3]; на зашифрованном не проверял - ровно, как раньше и описывал, прямо поверх зашифрованных секторов записано 4060h байт незашифрованного бэкапа GPT). После перезагрузки шел resync RAID'а (не эти диски, другие, не связанные вообще). Но на всякий случай.
Обновлено (вечер 27.08): Восстановил во всех своих специальных файлах специальные сигнатуры снова. Продолжаю наблюдение.
Motherboard: ASUS P9X79-PRO. Расклад по подключению HDD такой. Сейчас думаю сохранить, что может быть полезно для изучения сейчас или в будущем:
И в текущий момент все указывает на то, что странным образом уже дважды за последние сутки испортились данные только на тех трех HDD, которые подключены к контроллеру Marvell. При этом не имеет никакого значения: подключен диск напрямую внутри системы диск или через внешний eSATA BOX со сплиттером, зашифрован этот диск или нет. Пока что единственное, что отличает "испорченные" диски от "неиспорченных" - это то, что "испорченные" на контроллере Marvell, а "неиспорченный" (он один, но он не испорчен уже дважды) - на контроллере Intel.
Кстати, то, что ранее были испорчены все 4 диска может объясняться легко, т.к. я в какие-то периоды диски менял местами (они на салазках, это делается элементарно). Так что, если гипотеза верна, то диск с Intel'а мог легко на время оказаться на Marvell.
Обновлено (ночь 28.08):
Marvell 88SE91xx Adapter - BIOS v1.0.0.1031
Возможно, вот эта 1.0.0.x - это очень старая версия.
Потому что, например, контроллер Asmedia на этой плате 3TB HDD просто не поддерживал с драйверами, что шли от платы. (Я драйвера позже обновлял, но я не тестировал, исправилась ли эта проблема или нет - т.е. просто вначале проверил, он детектировал их как 746.52Gb и все, я забил; BIOS Asmedia тоже не обновлял).
Еще очень серьезный вопрос, конечно, к ASUS: какого черта они в своих .cap-файлах своего BIOS не вставляют новые BIOS'ы от Marvell и Asmedia? Почему я должен экспериментировать и вручную заменять их модули, предварительно вытащив их из BIOS'ов каких-нибудь других, более новых плат? Я вот, например, не хочу таких экспериментов (и лень). А что с теми домохозяйками, которые просто хотят использовать 3TB HDD "для фоточек" или там фильмов?
В общем, на текущий момент я четко уверен, что проблема связана с Marvell.
И расклад такой:
80% - что это старый BIOS Marvell'а (но какого черта он вообще что-то делает с дисками в момент инициализации/детекта?) и
20% - глючные драйвера Marvell'а (сейчас установлены самые последние!) (см. ниже, что не драйвера)
Обновлено (вечер 01.09) Это 100% EFI-драйвер от Marvell'а для BIOS (т.е. проблема актуальная для плат с UEFI BIOS'ами). Пример, как с таким же контроллером на обычном BIOS'е отсутствуют проблемы.
Обновлено (раннее утро 01.09): Вероятно, что это даже не BIOS, а еще веселее. EFI-драйвер от Marvell'а для BIOS'а (дизассемблировать его сейчас так же лень):
|139|MARVELL_ATAPEI |B87AAFF6-8E60-4D8E-8DAF-349962A4663C|00480998|000A1A|PEIM|
Т.е. обычный UEFI BIOS видит, что HDD с GPT-таблицей, далее читает последний сектор (для этого при работе со всеми контроллерами используются специальные EFI драйвера), видит, что там вместо GPT какой-то мусор (т.к. на самом деле вместо последнего сектора читает "последний сектор" mod 2^32 и находит там обычные данные или незанятые сектора), ну и принимает решение срочно сделать бэкап GPT туда.
ВЫВОД
Marvell 88SE91xx Adapter (Marvell 91xx SATA 6G Controller) с BIOS v1.0.0.1031
и/или
его драйвера версии v1.2.0.1038 (драйвера точно ни при чем, т.к. нашелся человек с Ubuntu, а там явно другие драйвера; а вот EFI-драйвера могут быть бажными)
НЕ ПОДДЕРЖИВАЮТ HDD больше 2.2TB корректно.
(И это достаточно свежий контроллер! 6G. Да и сама плата ASUS P9X79-PRO - когда я ее покупал, она вот только-только вышла. HDD объемом в 3TB уже давно в ходу были, но при этом два контроллера на этой плате - и Asmedia с драйверами по умолчанию, и, получается теперь, Marvell даже с самыми последними драйверами - не поддерживают 3TB HDD!).
Чтобы работать на таком контроллере с такими HDD - пользуйтесь инструкцией, изложенной ранее (раздел "Выводы"; создавайте специальный псевдо-бэд-секторный файл, который и будет вместо ваших данных портить BIOS этого контроллера или его драйвер).
Обновлено (ночь 01.09): Подтверждение того, что Windows, драйвера и проч. не причем, а проблема в контроллере (в железе/прошивке, скорее всего, в его BIOS или точнее - EFI-драйверах) в этом комментарии к посту. У человека линупс: системная плата ASRock H77 Pro4-M; BIOS: AMI P1.80 (02/25/2013) Revision: 4.6 (UEFI is supported); операционная система: Ubuntu precise (12.04.2 LTS), x64; HDD: Seagate ST3000DM001-9YN1 (SATA 3TB) 10 шт., Marvell контроллеры (две штуки!): Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s controller (rev 11). Те диски, которые подключены к motherboard - проблем по указанным смещениям не имеют. Те диски, что подключены к двум(!) контроллерам Marvell - все имеют бэкап-копию GPT таблицы по указанным мною смещениям, поверх пользовательских данных.
Формула для расчета
ВНИМАНИЕ!
Для дисков с другим размером смещение (сектор) будут другими!
В общем виде формула такая: бэкап пишется в последний сектор, берем номер этого сектора и считаем остаток от деления на 2^32 (из-за переполнения). Узнаем точный сектор куда нагажено сигнатурой "EFI PART". Вычисляем смещение. Вычитаем 4000h байт от смещения (т.к. всего нагажено 4200h) или вычитаем 32 сектора от секторов (т.к. нагажено всего 33 сектора) и узнаем начало, куда пишется мусор.
Пример:
2 ^ 32 = 4294967296
Диск 3TB (WD RED), последний сектор (десятичное число): 5860533167
Считаем номер сектора (десятичное число): 5860533167 mod 4294967296 = 1565565871 = 5D50A3AFh
Можно и проще, без вычислений, сразу переводим сектор в hex: 5860533167 = 15D50A3AFh
И берем от номера сектора только младшую часть (dword, 32 бита): 15D50A3AFh = 5D50A3AFh (получаем тот же результат)
Если надо, можем перевести в смещение: 5D50A3AFh * 200h (512) = BAA1475E00h (получаем уже знакомое ранее нам по моему тексту смещение).
По этому номеру сектора (или смещению - как удобнее) будет располагаться сигнатура "EFI PART". Учтите, это лишь конечный блок (сектор) загаживаемых данных. Т.е. от этого места нужно отматать чуть выше еще, чтобы найти начало (общий размер загаживаемых данных как в байтах, так и в количестве секторов был указан ранее).
Вычисляем смещение начала мусора (а не блок "EFI PART"): BAA1475E00h - 4000h = BAA1471E00h (начиная с этого смещения 4200h байт мусора или 33 сектора по 512 байт мусора).
Physical Sector No (полезен для уточнения при просмотре внутри Volume/Partition): BAA1471E00h / 200h = 5D50A38Fh = 1565565839
Диск 4TB (SeaGate и Hitachi), последний сектор (десятичное число): 7814037167
Считаем номер сектора (десятичное число): 7814037167 mod 4294967296 = 3519069871 = D1C0BEAFh
Или проще - берем от номера сектора только младшую часть (dword, 32 бита): 7814037167 = 1D1C0BEAFh => D1C0BEAFh
Считаем смещение по номеру сектора: D1C0BEAFh * 200h (512) = 1A3817D5E00h
Вычисляем смещение начала мусора: 1A3817D5E00h - 4000h = 1A3817D1E00h
Physical Sector No (полезен для уточнения при просмотре внутри Volume/Partition): 1A3817D1E00h / 200h = D1C0BE8Fh = 3519069839
_____________________
Я попробовал сейчас написать это в Marvell, чтобы они исправили. Правда, подозреваю, что Marvell мог это давно исправить в firmware (у меня BIOS v1.0.0.1031, но нашел в интернете, что есть v1.0.0.1033 - правда, не факт, что там что-то подобное исправлено). Просто ASUS не обновляет соответствующий набор в своем .cap-файле для BIOS'ов. Написал еще и в ASUS о проблеме.
Правильная формула для расчета смещения мусора.
Ну вот, наконец-то какая-то гадина опять записала в мои файлы. Из того, что я помню, что я делал "неординарного" - это запускал утилиту для просмотра SMART'а на всех дисках.
На зашифрованном диске записано прямо по Physical Disk (т.е. на зашифрованные сектора лег plaintext и при маунте/дешифрации вместо них отображается набор мусора -- дешифрация незашифрованного).
На всех остальных (незашифрованных) дисках - GPT / EFI PART, бэкап таблицы (при этом в последний сектор записано только 60h байт (96), т.е. не тронуто -- именно не тронуто -- 01A0h байт (416 байт), т.е. общий объем записанного 4200h - 01A0h = 4060h (16'480) байт. Остаточные 01A0h байт остались нетронутыми (прежние данные, мои сигнатуры).
Испорчено на всех дисках, кроме одного: [0x1x2x3]. Он остался с моими сигнатурами.
Сейчас восстановлю свои сигнатуры и попробую запустить эту утилиту опять.
Важно, что ядро ОС точно не влияет. В смысле, обновление не помогло.
Очень хорошо, что я понял проблему и сделал псевдо-бэд-сектора, иначе бы опять неизвестные файлы побились :)
Обновлено (ночь 27.08): Запуск двух SMART-тулз пока ни на что не повлиял. Гхм. Сейчас попробую поковырять в сторону фильтра диска.
Обновлено (день 27.08): С утра случился BSOD в iaStorA.sys (к вопросу качества драйверов Intel и к вопросу качества тестирования драйверов со стороны Microsoft - такое просто не допустимо), раз система перезагрузилась, решил заодно проверить файлы с левыми секторами. Посмотрел. Опять переписано поверх на нескольких дисках (на одном точно не переписано -- и это опять диск [0x1x2x3]; на зашифрованном не проверял - ровно, как раньше и описывал, прямо поверх зашифрованных секторов записано 4060h байт незашифрованного бэкапа GPT). После перезагрузки шел resync RAID'а (не эти диски, другие, не связанные вообще). Но на всякий случай.
Обновлено (вечер 27.08): Восстановил во всех своих специальных файлах специальные сигнатуры снова. Продолжаю наблюдение.
Motherboard: ASUS P9X79-PRO. Расклад по подключению HDD такой. Сейчас думаю сохранить, что может быть полезно для изучения сейчас или в будущем:
- Intel(R) C600 Series Chipset SATA AHCI Controller
Driver: iaStor.sys iaStorA.sys iaStorF.sys - v3.6.0.1086 (подпись от 10/2012), Intel (это из RSTe v3.6.0.1093 - последний на данный момент)- HDD5 [0x1x2x3] - внутри компьютера
- Marvell 91xx SATA 6G Controller
Driver: mv91xx.sys mvxxmm.sys mv91xxm.dll - v1.2.0.1027 (подпись от 06/2012), Marvell (есть новее - v1.2.0.1038 - не шибко новее, но все же новее)- HDD0 [0x4x4x0] - внешний eSATA/USB2 BOX (подключен через eSATA), низ
- HDD1 [8x8x5x5] - внутри компьютера
- HDD2 [2x3x4x1] - внешний eSATA/USB2 BOX (подключен через eSATA), верх; диск зашифрован
- Asmedia 106x SATA Controller
Driver: asahxp32.sys ahcipp32.dll - v1.3.8 (подпись без TS), Asmedia (есть новее - v1.4.1)
И в текущий момент все указывает на то, что странным образом уже дважды за последние сутки испортились данные только на тех трех HDD, которые подключены к контроллеру Marvell. При этом не имеет никакого значения: подключен диск напрямую внутри системы диск или через внешний eSATA BOX со сплиттером, зашифрован этот диск или нет. Пока что единственное, что отличает "испорченные" диски от "неиспорченных" - это то, что "испорченные" на контроллере Marvell, а "неиспорченный" (он один, но он не испорчен уже дважды) - на контроллере Intel.
Кстати, то, что ранее были испорчены все 4 диска может объясняться легко, т.к. я в какие-то периоды диски менял местами (они на салазках, это делается элементарно). Так что, если гипотеза верна, то диск с Intel'а мог легко на время оказаться на Marvell.
Обновлено (ночь 28.08):
- RAID resync закончился. Проверил: мои специальные данные по секторам на месте.
- Ради эксперимента запустил SMART-тулзы (обе), прощелкал все диски. После этого сделал sync. Проверил опять свои сектора: мои специальные данные на месте. Перезагружаю систему.
- Проверяю свои сектора: опаньки! Перезаписаны данные на 3-х дисках (включая шифрованный) -
на всех дисках, которые сидят на контроллере Marvell. На диске, который на Intel данные нетронуты
(мои метки на месте). - Восстановил свои сигнатуры на 3-х дисках. Обновил драйвер Asmedia. Никаких SMART-тулз не запускал. Перезагружаю систему.
- Проверяю свои сектора: опять то же! Перезаписаны данные на 3-х дисках... Опять не тронут Intel'овский.
- Не понимаю, но мне кажется, ранее перезагрузки не приводили к таким изменениям. Сейчас - стабильно. Каждая перезагрузка - снова испорчены сектора.
- Сейчас у меня опять идет resync RAID'а (так вышло случайно), что займет часов 12 - так что придется подождать. Данные секторов восстановил назад на свои специальные сигнатуры. Следующий этап: перезагрузить компьютер после resync, восстановить опять по секторам свои сигнатуры и попробовать обновить драйвер Marvell. После чего перезагрузить систему, опять посмотреть сигнатуры. Если опять испорчено, опять восстановить и перезагрузить (контрольная проверка). Дальше не знать над чем гадать :)
- Закончился resync RAID. Сигнатуры на месте. Перезагружать просто так не стал. Обновил драйвера Marvell. Сигнатуры на месте. Перезагружаюсь.
- Перезагрузился: все сигнатуры переписаны GPT-бэкапом. Опять на трех дисках. Опять их восстановил до своих сигнатур. На всякий случай еще раз перезагружаюсь (больше обновлять нечего, ну разве что BIOS еще, но он и так почти самый последний).
- Перезагрузился. Опять все испорчено :)
Marvell 88SE91xx Adapter - BIOS v1.0.0.1031
Возможно, вот эта 1.0.0.x - это очень старая версия.
Потому что, например, контроллер Asmedia на этой плате 3TB HDD просто не поддерживал с драйверами, что шли от платы. (Я драйвера позже обновлял, но я не тестировал, исправилась ли эта проблема или нет - т.е. просто вначале проверил, он детектировал их как 746.52Gb и все, я забил; BIOS Asmedia тоже не обновлял).
Еще очень серьезный вопрос, конечно, к ASUS: какого черта они в своих .cap-файлах своего BIOS не вставляют новые BIOS'ы от Marvell и Asmedia? Почему я должен экспериментировать и вручную заменять их модули, предварительно вытащив их из BIOS'ов каких-нибудь других, более новых плат? Я вот, например, не хочу таких экспериментов (и лень). А что с теми домохозяйками, которые просто хотят использовать 3TB HDD "для фоточек" или там фильмов?
В общем, на текущий момент я четко уверен, что проблема связана с Marvell.
И расклад такой:
80% - что это старый BIOS Marvell'а (но какого черта он вообще что-то делает с дисками в момент инициализации/детекта?) и
20% - глючные драйвера Marvell'а (сейчас установлены самые последние!) (см. ниже, что не драйвера)
Обновлено (вечер 01.09) Это 100% EFI-драйвер от Marvell'а для BIOS (т.е. проблема актуальная для плат с UEFI BIOS'ами). Пример, как с таким же контроллером на обычном BIOS'е отсутствуют проблемы.
Обновлено (раннее утро 01.09): Вероятно, что это даже не BIOS, а еще веселее. EFI-драйвер от Marvell'а для BIOS'а (дизассемблировать его сейчас так же лень):
|139|MARVELL_ATAPEI |B87AAFF6-8E60-4D8E-8DAF-349962A4663C|00480998|000A1A|PEIM|
Т.е. обычный UEFI BIOS видит, что HDD с GPT-таблицей, далее читает последний сектор (для этого при работе со всеми контроллерами используются специальные EFI драйвера), видит, что там вместо GPT какой-то мусор (т.к. на самом деле вместо последнего сектора читает "последний сектор" mod 2^32 и находит там обычные данные или незанятые сектора), ну и принимает решение срочно сделать бэкап GPT туда.
ВЫВОД
Marvell 88SE91xx Adapter (Marvell 91xx SATA 6G Controller) с BIOS v1.0.0.1031
и/или
его драйвера версии v1.2.0.1038 (драйвера точно ни при чем, т.к. нашелся человек с Ubuntu, а там явно другие драйвера; а вот EFI-драйвера могут быть бажными)
НЕ ПОДДЕРЖИВАЮТ HDD больше 2.2TB корректно.
(И это достаточно свежий контроллер! 6G. Да и сама плата ASUS P9X79-PRO - когда я ее покупал, она вот только-только вышла. HDD объемом в 3TB уже давно в ходу были, но при этом два контроллера на этой плате - и Asmedia с драйверами по умолчанию, и, получается теперь, Marvell даже с самыми последними драйверами - не поддерживают 3TB HDD!).
Чтобы работать на таком контроллере с такими HDD - пользуйтесь инструкцией, изложенной ранее (раздел "Выводы"; создавайте специальный псевдо-бэд-секторный файл, который и будет вместо ваших данных портить BIOS этого контроллера или его драйвер).
Обновлено (ночь 01.09): Подтверждение того, что Windows, драйвера и проч. не причем, а проблема в контроллере (в железе/прошивке, скорее всего, в его BIOS или точнее - EFI-драйверах) в этом комментарии к посту. У человека линупс: системная плата ASRock H77 Pro4-M; BIOS: AMI P1.80 (02/25/2013) Revision: 4.6 (UEFI is supported); операционная система: Ubuntu precise (12.04.2 LTS), x64; HDD: Seagate ST3000DM001-9YN1 (SATA 3TB) 10 шт., Marvell контроллеры (две штуки!): Marvell Technology Group Ltd. 88SE9123 PCIe SATA 6.0 Gb/s controller (rev 11). Те диски, которые подключены к motherboard - проблем по указанным смещениям не имеют. Те диски, что подключены к двум(!) контроллерам Marvell - все имеют бэкап-копию GPT таблицы по указанным мною смещениям, поверх пользовательских данных.
Формула для расчета
ВНИМАНИЕ!
Для дисков с другим размером смещение (сектор) будут другими!
В общем виде формула такая: бэкап пишется в последний сектор, берем номер этого сектора и считаем остаток от деления на 2^32 (из-за переполнения). Узнаем точный сектор куда нагажено сигнатурой "EFI PART". Вычисляем смещение. Вычитаем 4000h байт от смещения (т.к. всего нагажено 4200h) или вычитаем 32 сектора от секторов (т.к. нагажено всего 33 сектора) и узнаем начало, куда пишется мусор.
Пример:
2 ^ 32 = 4294967296
Диск 3TB (WD RED), последний сектор (десятичное число): 5860533167
Считаем номер сектора (десятичное число): 5860533167 mod 4294967296 = 1565565871 = 5D50A3AFh
Можно и проще, без вычислений, сразу переводим сектор в hex: 5860533167 = 15D50A3AFh
И берем от номера сектора только младшую часть (dword, 32 бита): 15D50A3AFh = 5D50A3AFh (получаем тот же результат)
Если надо, можем перевести в смещение: 5D50A3AFh * 200h (512) = BAA1475E00h (получаем уже знакомое ранее нам по моему тексту смещение).
По этому номеру сектора (или смещению - как удобнее) будет располагаться сигнатура "EFI PART". Учтите, это лишь конечный блок (сектор) загаживаемых данных. Т.е. от этого места нужно отматать чуть выше еще, чтобы найти начало (общий размер загаживаемых данных как в байтах, так и в количестве секторов был указан ранее).
Вычисляем смещение начала мусора (а не блок "EFI PART"): BAA1475E00h - 4000h = BAA1471E00h (начиная с этого смещения 4200h байт мусора или 33 сектора по 512 байт мусора).
Physical Sector No (полезен для уточнения при просмотре внутри Volume/Partition): BAA1471E00h / 200h = 5D50A38Fh = 1565565839
Диск 4TB (SeaGate и Hitachi), последний сектор (десятичное число): 7814037167
Считаем номер сектора (десятичное число): 7814037167 mod 4294967296 = 3519069871 = D1C0BEAFh
Или проще - берем от номера сектора только младшую часть (dword, 32 бита): 7814037167 = 1D1C0BEAFh => D1C0BEAFh
Считаем смещение по номеру сектора: D1C0BEAFh * 200h (512) = 1A3817D5E00h
Вычисляем смещение начала мусора: 1A3817D5E00h - 4000h = 1A3817D1E00h
Physical Sector No (полезен для уточнения при просмотре внутри Volume/Partition): 1A3817D1E00h / 200h = D1C0BE8Fh = 3519069839
_____________________
Я попробовал сейчас написать это в Marvell, чтобы они исправили. Правда, подозреваю, что Marvell мог это давно исправить в firmware (у меня BIOS v1.0.0.1031, но нашел в интернете, что есть v1.0.0.1033 - правда, не факт, что там что-то подобное исправлено). Просто ASUS не обновляет соответствующий набор в своем .cap-файле для BIOS'ов. Написал еще и в ASUS о проблеме.