Выравнивание разделов для запуска в реальном физическом секторе ssds / stripped raids / 4kB - этохорошее дело', но я столкнулся с проблемами при попытке сделать это для раздела truecrypt, который будет содержать ext3. Или так кажется.
Когда диск, о котором идет речь, правильно разбит на разделы и отформатирован с помощью ext3, я получаю очень разумную скорость записи около 70-80 МБ / с, но когда я помещаю поверх него truecrypt и ext3, производительность записи становится очень нестабильной и составляет 1-25 МБ / с с очень высокий io-подожди. На том же сервере у меня нет проблем с производительностью с ext3 поверх truecrypt на обычных дисках sata с сектором 512 ГБ и 500 ГБ. Итак, я предполагаю, что iowaits вызваны несовпадением, но я не могу найти достоверную информацию о том, как рассчитать оптимальное начало раздела. Я попытался запустить его с 128 логического сектора, я также пробовал сектор 8132, как предлагалось Вот но оба дали мне очень плохую и нестабильную работу.
Есть ли у вас опыт подобной установки? Спасибо!
ps - цитата с форума truecrypt: когда я зашифровал раздел с помощью Truecrypt, я получил только 8 Мбайт / сек, потому что он не помещает начало тома в сектор 8192, а вместо этого помещает том в конец дорожки, которой принадлежит 8192 к. У меня 63 сектора на дорожку, поэтому сектор 8192 - это второй сектор 130-й дорожки. Truecrypt начал свой объем в конце этой дорожки (номер сектора 8252), что на 60 секторов больше. Таким образом, решение заключалось в том, чтобы переместить раздел назад на 60 секторов, поэтому раздел начинался с 8132 вместо 8192. Это привело к тому, что первый сектор тома Truecrypt оказался в волшебном секторе 8192.
после некоторого поиска в 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.5TB диск был удален, установлен новый - все проблемы исчезли. так что это была проблема с оборудованием.
Добавляет ли TrueCrypt какие-либо блоки заголовков перед остальной частью раздела? Если это так, то это может фактически вывести ваши красиво выровненные разделы из строя. Вы можете попробовать намеренно смещать раздел на каждую возможную величину (это будет означать до 7 тестов, для различных способов, которыми блок 4k может быть отключен на 0,5k) и повторить ваши тесты. Если проблема заключается в том, что информация заголовка отодвигает основной массив данных от смещения, тогда один из этих тестов должен показать лучшие результаты, чем другие. Это предполагает, что любая добавляемая информация заголовка (или другая причина для смещения) составляет 512 байтов или несколько из них (что было бы разумно и, похоже, так, поскольку вы не видите аналогичного снижения производительности на дисках с 512-байтовыми секторами) .