Ich habe dieselbe Frage in der Mailingliste von eCryptfs gestellt. Dies ist der Thread -
http://comments.gmane.org/gmane.comp.file-systems.ecryptfs.general/294
Einer der Top-Mitwirkenden, Tyler Hicks, antwortete auf die Anfrage, hier kopiert (falls der Link nicht mehr funktioniert)
== BeginMessage ==
Ihre Testergebnisse sind für mich auf den ersten Blick nicht sinnvoll.
In den meisten Kernelversionen verwendet eCryptfs das Durchschreiben von Zwischenspeichern. In einigen Kernel-Releases wurde ein Write-Back-Cache implementiert, der jedoch einige Probleme verursachte und der Patch zurückgesetzt wurde.
Für die SUM-Abfrage, die Sie ausführen, würde ich erwarten, dass alle Lesevorgänge ausgeführt werden. Rückschreiben oder Durchschreiben sollten daher keine Rolle spielen. Es gibt eine Ebene für das Caching der verschlüsselten Seiten im unteren Dateisystem und dann eine weitere zwischengespeicherte Ebene der entschlüsselten Seiten auf der eCryptfs-Ebene. Dies ist sicherlich etwas anderes als bei der Verwendung von nur ext4.
Sie sprachen über das Löschen der MySQL-Puffer und des eCryptfs-Seitencaches (durch das Aufheben der Bereitstellung von eCryptfs und das erneute Bereitstellen von eCryptfs) zwischen den Tests. Es gibt immer noch den unteren Cache des Dateisystems, der nicht gelöscht wird. Vielleicht hat das etwas damit zu tun, aber ich bezweifle, dass dies die ganze Geschichte ist.
Verwenden Sie innodb_flush_method = O_DIRECT? eCryptfs implementiert keine direkte E / A, daher bin ich mir nicht sicher, wie MySQL dies zusätzlich zu eCryptfs vs. ext4 handhaben würde, was direkte E / A bewirkt.
Dies ist etwas, was ich mehr herausfinden müsste, um einen Sinn daraus zu machen. Was Sie sehen, ist definitiv seltsam.
== Ende der Nachricht ==