ECryptfs предварительно выбирает и / или буферизует данные?

Question

Я экспериментировал с использованием eCryptfs в качестве основной файловой системы для данных MySQL, чтобы имитировать прозрачное шифрование данных для MySQL. Я провел несколько тестов, чтобы измерить издержки дешифрования, когда MySQL читает данные, и я получаю странные результаты.

Я подготовил таблицу размером 7,5 ГБ и выполнил запрос на полное сканирование таблицы (SUM). У меня есть два сценария -

1. Когда базовый fs является ext4 и не шифруется, среднее время запроса на несколько запусков - 22,5 секунды.
2. eCryptfs установлен поверх ext4 -
   • Когда таблица создается впервые, среднее время выполнения запроса составляет 21 секунду (поскольку он меньше, чем незашифрованный, есть ли какая-то предварительная выборка?)
   • Очистите буферы MySQL и повторите запрос, среднее время выполнения теперь составляет 9,6 секунды (из-за буферизации eCryptfs?)
   • Если я размонтирую свой каталог и перемонтирую его, но не буду воссоздавать данные, среднее время составит около 17 секунд. Это снова загадочно. Сохраняла ли eCryptfs некую зашифрованную мета-информацию, когда она была дешифрована в первый раз?

Я запускал эти тесты несколько раз (каждый раз очищая буферы MySQL) и получал непротиворечивые результаты. Может кто-нибудь объяснить или указать мне ресурс, который объясняет это поведение? Можно ли это отключить (для тестов)?

Answer 1

Я задал тот же вопрос в списке рассылки eCryptfs. Это нить -

http://comments.gmane.org/gmane.comp.file-systems.ecryptfs.general/294

Один из лучших авторов, Тайлер Хикс, ответил на запрос, скопированный сюда (в случае, если ссылка не работает)

== BeginMessage ==

Результаты вашего теста не имеют смысла для меня на первый взгляд.

В большинстве версий ядра eCryptfs использует сквозное кэширование. Было несколько выпусков ядра, в которых был реализован кэш обратной записи, но это вызвало некоторые проблемы, и этот патч был отменен.

Для запроса SUM, который вы выполняете, я бы ожидал, что он будет все для чтения, поэтому обратная запись или сквозная запись не должны иметь большого значения. Там будет слой кэширования зашифрованных страниц в нижней файловой системе, а затем еще один слой кэширования дешифрованных страниц на уровне eCryptfs, поэтому он, безусловно, отличается от того, когда вы просто используете обычный ext4.

Вы говорили об очистке буферов MySQL и кэша страниц eCryptfs (путем размонтирования и перемонтирования eCryptfs) между тестами. Все еще есть нижний кеш страниц файловой системы, который не очищается. Может быть, это как-то связано с этим, но я сомневаюсь, что это полная история здесь.

Вы используете innodb_flush_method = O_DIRECT? eCryptfs не реализует прямой ввод / вывод, поэтому я не уверен, как MySQL справится с этим поверх eCryptfs по сравнению с ext4, которая делает прямой ввод / вывод.

Это то, что я должен изучить больше, чтобы понять это. То, что вы видите, определенно странно.

== Конец сообщения ==