Выравнивание раздела truecrypt на диске сектора размером 1,5 ТБ, 4 КБ

Выравнивание разделов так, чтобы они начинались с реального физического сектора дисков ssds / stripped raids / 4kB - это " хорошая вещь", но я столкнулся с проблемами при попытке сделать это для раздела truecrypt, который будет содержать ext3 на нем. Или так кажется.

Когда соответствующий диск правильно разделен и отформатирован с использованием ext3, я получаю очень разумные скорости записи около 70-80 МБ / с, но когда я помещаю truecrypt и ext3 поверх него, производительность записи становится очень нестабильной и колеблется между 1-25 МБ / с с очень высокий ио-подожди. На том же сервере у меня нет проблем с производительностью ext3 на вершине truecrypt на обычных дисках sata емкостью 512B в секторе 500GB. Поэтому я думаю, что iowaits вызваны смещением, но я не могу найти надежную информацию о том, как рассчитать оптимальное начало раздела. Я пытался запустить его на 128 логическом секторе, я также пробовал 8132 сектора, как предложено здесь, но оба дали мне очень плохую и нестабильную производительность.

Есть ли у вас опыт с подобной настройкой? Спасибо!

ps - цитата из форума truecrypt: Когда я зашифровал раздел с помощью Truecrypt, я получил только 8 Мбайт / с, потому что он не помещает начало тома в сектор 8192, а вместо этого помещает том в конец дорожки, которой принадлежит 8192 к. У меня есть 63 сектора на дорожку, поэтому сектор 8192 является вторым сектором 130-й дорожки. Truecrypt начал свой объем в конце этой дорожки (сектор номер 8252), что на 60 секторов слишком далеко. Таким образом, решение состояло в том, чтобы переместить раздел обратно на 60 секторов, чтобы раздел начинался с 8132 вместо 8192. Это привело к тому, что первый сектор тома Truecrypt был расположен в магическом секторе 8192.

2 ответа

Решение

После некоторого поиска в Google и нескольких собственных тестов я пришел к выводу, что это неисправный диск. другие имеют аналогичную проблему с дисками WD15EADS. длительный тест на правильно выровненном разделе ext3 также показал снижение производительности.

я бегал в цикле:

dd if=/dev/zero of=/mnt/1_5tb0/out bs=1MB count=45000

и получил ухудшение производительности:

45000000000 bytes (45 GB) copied, 652.667 s, 68.9 MB/s
45000000000 bytes (45 GB) copied, 648.647 s, 69.4 MB/s
45000000000 bytes (45 GB) copied, 645.147 s, 69.8 MB/s
45000000000 bytes (45 GB) copied, 655.122 s, 68.7 MB/s
45000000000 bytes (45 GB) copied, 644.662 s, 69.8 MB/s
45000000000 bytes (45 GB) copied, 645.12 s, 69.8 MB/s
45000000000 bytes (45 GB) copied, 648.025 s, 69.4 MB/s
45000000000 bytes (45 GB) copied, 650.528 s, 69.2 MB/s
45000000000 bytes (45 GB) copied, 1247.87 s, 36.1 MB/s
45000000000 bytes (45 GB) copied, 1601.76 s, 28.1 MB/s
45000000000 bytes (45 GB) copied, 1776.75 s, 25.3 MB/s

в какой-то момент система почти останавливается с очень высоким iowait + очень низкой активностью диска в iostat [например, 2-10 iops/sec ].

пс.: предыдущий диск 1,5 ТБ был удален, установлен новый - все проблемы исчезли. так что это была проблема с оборудованием.

Добавляет ли TrueCrypt какие-либо блоки заголовков до остальной части раздела? Если это произойдет, то это может привести к тому, что ваши хорошо выровненные разделы вернутся из строя. Вы можете попытаться преднамеренно сместить раздел по каждому возможному количеству (это будет означать до 7 тестов, для разных способов, когда блок 4k может быть отключен кратным 0,5k) и повторить ваши тесты. Если проблема заключается в информации заголовка, которая отталкивает основную часть данных от смещения, тогда один из этих тестов должен показывать лучшие результаты, чем другие. Это предполагает, что любая добавляемая информация заголовка (или другая причина смещения) составляет 512 байт или кратно ей (что было бы разумно, и, похоже, имеет место, поскольку вы не видите подобного снижения производительности на дисках с 512-байтными секторами),

Другие вопросы по тегам