Я задал тот же вопрос в списке рассылки 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, которая делает прямой ввод / вывод.
Это то, что я должен изучить больше, чтобы понять это. То, что вы видите, определенно странно.
== Конец сообщения ==