On Fri Jan 28, 2011 at 03:18:38AM -0000, Dustin Kirkland <email address hidden> wrote:
> time dd if=/dev/zero of=~/dummy bs=512 count=10240
There are a couple issues here:
1. eCryptfs currently implements a write-through cache. This means that
reads are cached, but writes are not. There's currently someone
investigating a switch to a proper write-back cache on files opened
without the O_SYNC flag. This would result in writes being cached
and, more importantly, write() returning before the page is
encrypted. Some rough, initial tests show a very nice improvement.
2. bs=512 results in a 4 writes to a single page, meaning that single
page is encrypted 4 times in a row and dd has to wait on the page
encryption and writing 4096 bytes to the lower filesystem every
time. This is why doing what I talked about in #1 has so much
potential to increase performance.
Encryption isn't free, but we should be a little smarter about when we
do it.
On Fri Jan 28, 2011 at 03:18:38AM -0000, Dustin Kirkland <email address hidden> wrote:
> time dd if=/dev/zero of=~/dummy bs=512 count=10240
There are a couple issues here:
1. eCryptfs currently implements a write-through cache. This means that
reads are cached, but writes are not. There's currently someone
investigating a switch to a proper write-back cache on files opened
without the O_SYNC flag. This would result in writes being cached
and, more importantly, write() returning before the page is
encrypted. Some rough, initial tests show a very nice improvement.
2. bs=512 results in a 4 writes to a single page, meaning that single
page is encrypted 4 times in a row and dd has to wait on the page
encryption and writing 4096 bytes to the lower filesystem every
time. This is why doing what I talked about in #1 has so much
potential to increase performance.
Encryption isn't free, but we should be a little smarter about when we
do it.