Вопрос или проблема
У меня есть внешний HDD (не SSD), который показывает:
Размеры секторов: 512 байт логический, 4096 байт физический
Должен ли я использовать --sector-size 512 или --sector-size 4096 с cryptosetup LuksFormat? Использование параметров по умолчанию (не уверен, пытается ли он автоматически определить или всегда использует 512) привело к значению 512.
Если это имеет значение, настройка будет следующим образом: [disk]->[gpt3]->[physical partition]->[LUKSv2]->[btrfs]
Итак, я использовал оба способа, чтобы собрать результаты тестов:
512
# sysbench fileio prepare
2147483648 байт записано за 34.28 секунды (59.75 MiB/сек).
# sysbench fileio --file-test-mode=rndrw run
Дополнительные флаги открытия файла: (нет)
128 файлов, по 16MiB каждый
Всего 2GiB размер файла
Размер блока 16KiB
Количество запросов ввода-вывода: 0
Соотношение чтения/записи для комбинированного теста случайного ввода-вывода: 1.50
Периодический FSYNC включен, вызов fsync() каждые 100 запросов.
Вызов fsync() в конце теста, включен.
Используется режим синхронного ввода-вывода
Проводится тест случайного чтения/записи
Инициализация рабочих потоков...
Потоки запущены!
Операции с файлами:
чтений/сек: 14.42
записей/сек: 9.62
fsyncs/сек: 31.25
Пропускная способность:
чтение, MiB/сек: 0.23
запись, MiB/сек: 0.15
Общая статистика:
общее время: 12.4778 сек
общее количество событий: 562
Задержка (мс):
мин: 0.00
сред: 17.84
макс: 365.73
95-й процентиль: 84.47
сумма: 10024.98
Справедливость потоков:
события (сред./ст. откл.): 562.0000/0.00
время выполнения (сред./ст. откл.): 10.0250/0.00
# sysbench fileio --file-test-mode=seqrewr run
Дополнительные флаги открытия файла: (нет)
128 файлов, по 16MiB каждый
Всего 2GiB размер файла
Размер блока 16KiB
Периодический FSYNC включен, вызов fsync() каждые 100 запросов.
Вызов fsync() в конце теста, включен.
Используется режим синхронного ввода-вывода
Проводится тест последовательной перезаписи
Инициализация рабочих потоков...
Потоки запущены!
Операции с файлами:
чтений/сек: 0.00
записей/сек: 815.93
fsyncs/сек: 1045.19
Пропускная способность:
чтение, MiB/сек: 0.00
запись, MiB/сек: 12.75
Общая статистика:
общее время: 10.0488 сек
общее количество событий: 18576
Задержка (мс):
мин: 0.00
сред: 0.54
макс: 433.66
95-й процентиль: 0.02
сумма: 9996.57
Справедливость потоков:
события (сред./ст. откл.): 18576.0000/0.00
время выполнения (сред./ст. откл.): 9.9966/0.00
##4096
# sysbench fileio prepare
2147483648 байт записано за 28.85 секунд (70.99 MiB/сек).
# sysbench --test=fileio --file-test-mode=rndrw run
Операции с файлами:
чтений/сек: 26.17
записей/сек: 17.45
fsyncs/сек: 58.35
Пропускная способность:
чтение, MiB/сек: 0.41
запись, MiB/сек: 0.27
Общая статистика:
общее время: 11.4636 сек
общее количество событий: 1041
Задержка (мс):
мин: 0.00
сред: 9.63
макс: 370.49
95-й процентиль: 44.98
сумма: 10021.97
Справедливость потоков:
события (сред./ст. откл.): 1041.0000/0.00
время выполнения (сред./ст. откл.): 10.0220/0.00
# sysbench fileio --file-test-mode=seqrewr run
Операции с файлами:
чтений/сек: 0.00
записей/сек: 1229.02
fsyncs/сек: 1574.44
Пропускная способность:
чтение, MiB/сек: 0.00
запись, MiB/сек: 19.20
Общая статистика:
общее время: 10.0071 сек
общее количество событий: 27929
Задержка (мс):
мин: 0.00
сред: 0.36
макс: 471.49
95-й процентиль: 0.02
сумма: 9997.75
Справедливость потоков:
события (сред./ст. откл.): 27929.0000/0.00
время выполнения (сред./ст. откл.): 9.9978/0.00
Для искусственно малых файлов 4K кажется вдвое быстрее при чтении и в 0.25 раза быстрее при записи.
Еще одна правка. Сделал тот же тест, но с копированием 110G пакета файлов размером от 2.5 Mb (95% персентиль) до 300 Mb.
Оба диска, форматированные в 512 и 4096, заняли 20м30с +-4с
Диски с 4К секторами, но с отчетом о логических секторах 512 байт, известны как диски “Advanced Format” (AF). Они эмулируют сектора размером 512 байт. Однако они делают это неэффективно; например, чтобы записать сектор размером 512 байт, диск должен прочитать текущие 4К данных, обновить необходимые данные и записать результат. Это дополнительный этап “чтения”, который не нужен при записи 4К секторов.
Вы можете увидеть результат в ваших тестах; тесты с 4К работают намного быстрее.
Обратите внимание, это также относится к разделению диска; убедитесь, что ваши разделы выровнены по 4К, иначе каждая запись, выполняемая ОС, может затронуть 2 сектора! Инструменты, такие как fdisk, предупредят об этом несовпадении.
Единственный минус использования 4К секторов заключается в том, что вы можете потерять полезное пространство; например, если вы создадите файл размером 300 байт, он займет 4К на диске, тогда как с секторами 512 байт он займет только 512 байт. Я считаю это справедливым компромиссом ради повышения скорости.
Таким образом, в вашем случае я бы использовал 4К сектора с cryptsetup.
Ответ или решение
При выборе сектора для шифрования с помощью LUKS (Linux Unified Key Setup), этот вопрос стоит очень остро на фоне возрастающей важности защиты данных. Решая, какой размер сектора выбрать — физический 4096 байт или логический 512 байт — необходимо, в первую очередь, учесть теоретические аспекты, провести анализ предоставленных тестов, а затем применить эти знания в вашем конкретном случае.
Теория
Современные жесткие диски, такие как описанный в вашем вопросе, часто используют технологию, известную как "Advanced Format" (AF). Эти диски имеют физический размер сектора 4096 байт, но эмулируют логические секторы размером 512 байт. Эмуляция позволяет программному обеспечению (операционным системам и приложениям) работать с новыми жесткими дисками, как если бы они были старыми дисками с секторами в 512 байт. Однако, такая эмуляция, как правило, влечет за собой некоторые задержки и снижение производительности из-за необходимости чтения и записи лишних данных.
На уровне теории, используя 4096-байтовые секторы, мы сокращаем количество операций ввода-вывода, необходимых для выполнения той же самой работы, в сравнении с использованием 512-байтовых секторов. Уменьшение количества операций просмотра и записи напрямую сказывается на производительности системы. Более того, использование сектора, совпадающего с физическим размером, уменьшает вероятность возникновения проблем с выравниванием, что потенциально может приводить к ухудшению производительности.
Пример
Согласно предоставленным вами данным из тестов, использование 4096-байтовых секторов показало значительно более высокую производительность, чем 512-байтовые. Особенно это заметно при последовательной записи, где объём записи и скорость практически в полтора раза выше, чем при использовании меньших секторов. Это явное преимущество, особенно если вы используете диск для хранения больших файлов, где минимизация накладных расходов на операциях ввода-вывода может существенно повлиять на общее время работы с системой.
Применение
С практической точки зрения, при выборе конфигурации для шифрования диска с помощью cryptsetup LuksFormat, очень важно учитывать тип данных, который вы планируете хранить, и характер их использования. Для больших файлов и приложений, которые осуществляют интенсивные операции чтения и записи, использование 4096-байтовых секторов — это оптимальный выбор, дающий наибольшее повышение эффективности.
Дополнительно обратите внимание на разметку диска. Важно, чтобы все разделы были выровнены правильно в соответствии с границами 4096 байт, чтобы избежать ситуации, когда операции записи задевают соседние сектора, что может снизить производительность. Современные утилиты разметки, такие как fdisk, автоматически предупреждают о возможных проблемах выравнивания и предлагают их исправить.
Единственным потенциальным недостатком использования 4096-байтовых секторов может быть неэффективное использование пространства при хранении большого количества мелких файлов, так как для каждого из них будет затрачиваться целый сектор в 4096 байт, в отличие от 512 байт. Однако, если основное внимание уделяется производительности, этот компромисс стоит преимуществ, которые вы получите.
Подводя итог, в вашем случае рекомендуется использовать 4096-байтовые сектора с cryptsetup, особенно учитывая тестирование, указывающее на улучшение производительности. Этот подход будет наиболее эффективным в контексте ваших требований и обеспечит более оптимальные результаты работы системы.